Hi
I want to move an original file from desktop to DXO
Thank you both
PhotoLab doesn’t have its own file storage - it simply opens files that are located on your hard disk.
Assuming you have placed a file on your desktop, if you wanted to, there is no reason why you can’t edit it in place - at which point PhotoLab will create a DOP sidecar next to it on the desktop. But it is far better to organise your files in suitable folders, so that the desktop doesn’t get cluttered.
Maybe you are thinking of Apple Photos, where you import files into its library by dragging them into the Photos window? At which point, Photos places the files in its own internal folder structure. This is not how PhotoLab works.
Use Finder to create folders and sub-folders to you liking under the Pictures folder (or anywhere else if you want) and then simply use the tree view in PhotoLab to locate them.
In Windows it’s just to select the images in the File Manager/Explorer and then drag them to the “Filmstrip” in the open Photolab.
That will not “move” the images but just opening them like Photolab always do.
One good thing is that Photolab remembers these external actions and you can always just clic on the list of external references in Photolab to fill the Filmstrip with the images referenced in the selected reference in the list.
I use this a lot since even external applications like Photo Mechanic leaves references like that in Photolab when using the “Edit”-function in PM Plus.
Another Mac-Win difference?
So you can’t do that from the Finder in Mac?
I think that is one of the really nice integration features Photolab has and it’s pretty seamless with Photo Mechanic.
In fact that was one thing that first didn’t work properly, but Kirk Baker at Camera Bits fixed that both for Photolab and PureRaw. In the beginning it just opened one image regardless of how many images one had selected.
Actually, I just tried dragging a file from the desktop into the filmstrip and it did, indeed, set the active folder to the desktop and open the file for editing.
Who’d have thought it? Come to that, why would you want to?
I still maintain, you shouldn’t be editing images if they are on the desktop.
I think you might misunderstand. You can drag them from anywhere in the file system or via an application that interacts with Photolab. This is an absolute killer feature to be able to for example select a selection of RAW-images in for example Photo Mechanic and just with a right click activate the function Edit Images with - > Photolab (or Pure RAW) in PM Plus and in a few seconds the images are opened in Photolabs filmstrip.
In fact Photo Mechanic uses this “drag and drop”-feature behind the curtain to perform this trick according to Kirk Baker at Camera Bits.
Selecion of images in PM Plus
The images are opened in Photolabs “Filmstrip” with the first open for editing. This image shows by the way a simple “koja” or shelter the loggers i Hälsingland in the central forrests of Sweden used to live in when cutting timber in the winters. Transportation was poor so they had to stay out there when working. Between -30 centigrades and below that was not unusual these days.
At the same time there is a link created to these images in Photolabs “External Selections” where they can be opened later if necessary with just a click.
quote:
“Come to that, why would you want to?”
One other reason to use this feature is not to get stuck in a wait state when Photolab starts to render or update previews when opening a folder with many houndreds of heavy images. With this integration you have a tool to open just the images you really want to edit which makes you much more effective and in this case you are making your searches towards the XMP-metadatabase of PM Plus instead of the filesystem directly.
When I first saw what DXO and Camera Bits had done my jaw just dropped. I just love that feature!
It´s also easy to create a “Project” of an “External Selection” and “name it” to make it easier to handle. The “External Collections” are just saved with a time stamp and the number of images it contains.
The way to work with this is to have Photolab open.
That’s nothing so super special, @Stenis , each RAW-converter with integrated DAM (worth the name) can do this by creating a collection / album from selected pictures. The super special bit is the interaction of two very different apps - but then, at the costs of these two apps I would expect it to work better than RAW converters with integrated DAM.
Sorry, all of us are different. To you it’s a killer-feature, to me it’s basic function in any RAW-converter with integrated DAM.
The next sentence is generally spoken, not to you: I’m sooo bored by the constant celebration of DxO PL not needing a database and doing everything with just the DOP-files - which is a plain self-deception - and at the same time using all kind of databases built from companies which are not related to DxO. Costs are extending, usability is decreasing. Like eating a diner in a restaurant, but for the wine you have to walk over the street and consume it in the bar, and afterwards back to the dish.
I love the comparison 
The killer feature is that it´s as good as it is with Photo Mechanic which is third party. PM is much more like an Enterprise like DAM than either Lightroom or Photolab. Of course an integrated software should be well oiled with the converter tools but they are also pretty inefficient compromises too in other respects. That´s why I don´t really like Lightroom and has ceased using since almost 10 years.
I´m used to more of the Enterprise DAM systems with strong and efficient metadata functions and being able to integrate that with Photolab is really the best of the two worlds without any real compromises for me.
The cost concern is more for people not valueing their time really. A little more than 200 U$ is a real bargain for me for full blown metadata tools and a really efficient metadatabase and photo library.
And I’m used to Aperture - which once also was really expensive. If I recall correctly, in the 500-600 $ range. Later, from version 2 or so, it was 1/3 of the price. As my main concern never was to share or sell images and present them in a searchable structure, I could easily get along with folders, albums, projects, groups + smart albums. Tagging each image with keywords is not exactly a time saver, as long as I can find images by grouping them into more or less crude collections.
I can understand your motivation to tag images with keywords, but for my purpose it’s a lot of wasted time as nobody else benefits of it. Downside of tagging is, you need to do it constantly and it’s not exactly dynamically updating.
5 years ago I would have tagged a picture “bird” + “animal”, two years later maybe “duck”, one year later “goosander” and half year later additionally “mergus merganser” - and except the latin name all would be in German - why should I tag in another language than my native one? But going back through all “bird” pictures to find goosanders I took a snap from 6 years ago? And what with “female” and “male”? Keywords are never enough. But I don’t use a photocamera when I afterwards have to write a small letter filled with keywords to describe the content. Then I could save the costs of camera gear, software licenses and get myself a couple of notebooks.
As I understood, you’re sharing/selling pictures with/to others, so you have a good reason to do the extra work. While for me and my projects of photobooks, slideshows, web-galleries keywords are the least necessary thing. That’s my reason to wish for a well integrated DAM - keywords are not the only possiblity to organize images.
1 Like
We’re off topic now, but for birds, check out this thread:
https://forum.dxo.com/t/import-merge-export-keyword-list-s/21079
Excause me for the late response Joachim.
I have to say there is absolutely nothing wrong with a good folder structure with folders with good descriptive labels as a starting point when building a XMP-metadata index. In fact it helps a lot when starting since both folder names and image names are indexed too. That job we have once done with naming files and folders are by no means wasted because we build XMP-metadata indexes on top of them.
Even when converting old “Image Silos” into Enterprise DAM XMP-indexes folder names can be a good starting point even if these systems mostly are rigged to build the folder structure automatically when new images are appended. It is good though to establish “a top folder” where all your other main image folders are contained. Then it becomes very easy to create or maintain the XMP-metadata index from one single point, both in Photo Mechanic Plus and when “reading/import” this index from Photolab.
One of the advantages with software like PM Plus is that it supports an abundance of variables that are very handy when we need to automate some data entries in maintainance templates. It saves a lot of time and adds lots of important metadata to the images. This is many times very much more important than the keywording. I think the keywording is mostly for my own use and effectivity when working with my image library. I also avoid using the word archive since I think that word has a too static meaning for the way I use my image library.
I rarely sell any images and applying metadata to the images I have processed I do of two reasons. The first is that I have 70 000 images despite I still have many for me intresting analogue positive film images that are not digitized yet and before PM Plus saved me that was a constant headache. When I started to use it I just could’t believe what I got for a couple of houndred U$. The core of PM Plus is very much what you can find in Enterprise systems and I think we spent between 100 000 to 200 000 U$ building The Digital City Museum of Stockholm and that was just for the software and what one consultant costed setting up the DAM initially.
The second reason is that I make “foto stories/foto reports” and publish them at Swedens biggest photo community and if I tag them people will find both these images and my stories via Google and that is a great advantage. If someone search Google with my “anglicised” name “sten-ake sandh” insted of the swedish “sten-åke sändh” they will still find quite a few of my blogg images which all are tagged in english Tagging in local languages should be avoided if the images are going to be published on the Internet.
Below is another example where just searching for the name of the unique printing process of “Direktlito” used for 15 years at the biggest swedish morning paper, leads both to the 10 plus images in my blogg about it (if you follow the link through one of the images.
Direktlito was invented and patented at a small swedish paper called Västerbottens Kuriren in the seventies when the old lead based “book printing” rotation printing presses had to be replaced OR rebuilt in order to be able to support the then new digitized workflows at the papers. The thick lead printing plates were replaced with a “distance” and on top of them regular offset plates.
Here is the link to the story and the blog:
Sten-Åke Sändh - Stenis Fotoblogg - Fotosidan
I think you are absolutely right about that. It’s not very smart spending a lot of time adding metadata if you don’t really can justify the effort but as I hope I have managed to describe above there is a lot to gain using XMP-metadata baked into your JPEG:s on the Internet if you want to reach out to a wider audience.
Should have made that clearer: The last versions of Aperture had folders, Capture One today has groups instead. I didn’t talk about file system structures, only structures within the DAM. All images were connected to the DAM just by links to either the externally referenced files or the internally stored (within the library package). That way I don’t need to copy the big RAWs. It was the way I learnt to organize images - not easy in the beginning as working with “unreal” (=only referenced) images felt usafe. It tales a while to trust the database. And it doesn’t feel “safe” in the beginning and at that time I din’t juggle around with a couple of Terabytes, the library was small enough to keep it on the internal drive.
When I look at Apple’s Aperture successor “Photos” I can only see: Apple’s answer to growing libraries, files sizes and decreasing homebound working is “iCloud”. Managing local storage is no longer the way to go for them. I don’t know any film photographer who goes to a public library to store his or her negatives. It feels wrong to me, as does the cloud.
This is simple to understand. The more they can push your stuff onto iCloud, the more you have to pay for that storage space. Cold, hard cash (or a credit card 
)
Does it help top keep the credit card in the fridge? In terms of cold and harsh… 
In a way, my zoo of harddrives might cause more energy (and material) consumption than scalable servers. But at some time I will loose control over my own images, and this is nothing I’m looking forward to. No wonder, film phtography is not dead yet.
This is one reason why we are starting to do more printing. A3+ for the “ordinary” that are worth printing and, thanks to our new “toy” (Canon A2 printer), we are now doing the really special ones on that and mounting on foam-core instead of framing.
There is doubt that proprietary image databases can be very tempting solutions. They are often easy to use with low tresholds for the users but the ugly backside is that they are just proprietary and often not so easy to migrate from and that fact often creates an enclosure that is not so easy to get out of and that might just one of the design goals for the manufacturer of these systems.
In one way or another there is always files and folders at the very bottom of the systems but with an open standard as XMP there is no need to move any files - they are incorporated in the XMP-indexes from where they are. After they are indexed and previews are made everything takes place virtually without reading the original files. That is why these XMP-based indexdatabases are so fast since they just use smaller previews.
It´s also very safe since the metadata are owned by and attached to the files (RAW) or baked into the XMP compatible image file types like JPEG, TIFF and DNG. TIFF should be avoided since it is a pretty inefficient file format in DAM-systems because it lacks a defined XMP-header like JPEG and DNG. In automation processes where images are processed by DAM an automation hub images are even physically moved between folders when they are processed which makes TIFF not ideal. If and XMP-database gets corrupt it´s no real security problem since it´s just to reindex the folder structure and the files. If a proprietary monolithic metadata database gets currupted you are facing a single point of failure that just happened. Then you are totally dependent on a backup to restore. With a distributed metadata system like XMP you really don´t even need a backup of the database since the data is owned by the files. You don´t need anything to restore - you just need to reindex.
A tif-file is the way to go to exchange high quality pics between different editing programs, that are otherwise not compatible – regardless of any DAM.
1 Like