Well guys,
as I understand - first you failed with a business project which had nothing to do with the Photolab, then you waisted time with the DAM feature intended to attract potential users, and now the actual users have to pay for it…
2 Likes
I use Photo Supreme, simple why I am badly dyslexic and adding and searching by words is more than an interesting thing for me. With PS I can get the spelling for categories and other entries and when indexing images the entered categories get displayed as you start to type. If the worst comes to bare just bring up the full list. Searching is just gragging terms needed into the search box, for me simple. Any hope of DxO managing this, about as mush likelihood as the DxO One being susseffull. DAM’s produced by others have been under development for years and there strengths are based on it. OP is a RAW editor and to me its mad to spread thin resources over a new area when there are masses of camera/lens outstanding let alone years of under development with the core program thanks to the One. To me there is more basis for developing Fujifilm compatibility, given the long standing demand there has been for this.
1 Like
Please, please stick to the XMP standards when implementing DAM features. I am afraid you will create a lot of problems to people that use a professional DAM as PSU when you are handling Exif only. This said I also prefer a refinement of PL as RAW developer over extended DAM features.
2 Likes
ok you got a point.
exif vs xmp
Edit, only the third post was interesting but it got some inside.
this explains more what the difference is.
Doesn’t matter which file just please no library by indexing in a working application.
exif is present from the start profided by rawfile and xmp needs to be baked.
But then again i am not used to thousands and thousands of image every month. so…
1 Like
I totally agree with Alec above.
DxO being “just” a raw converter was a very heavy argument for me to NOT get Lightroom. I don’t want to be forced to use huge libraries or the like - I am able to organize my data by myself.
I strongly like the UI and workflow with DxO, and I prefer it to every other RAW developer I tested so far.
People who (think they) need DAM should do this by using specialized DAM tools. Instead of adding unwanted and incomplete features into DxO, it would be much better to get the already existing core functions fully performant (example: auto masks in local adjustments is crap right from the start; I’ve been waiting a full year to see this corrected, but apparently that’s not addressed in PL 2 by any means).
Tilmann
5 Likes
Ok, did some reading about what Exif, IPTC XMP is and how we can use it.
(I don’t have a large amount of images every month so i never bothered to label and tag my raw files other then folders with date and place. I do tag and label more detailed the processed files as a Jpeg. (i use the PSE Organisor for this.) Which has its quirks.
- changing quarded/watched folders outside the application does corrupt the library and repairing is time consuming. (so i always keep every thing out its grip until i am satisfied and only then i place the folder with new images in a special “import folder for DAM”
Why i am telling you this? Well before i place it in this folder, the EXIF data is the only image data in the jpeg or rawfile. The sidecar which DxO provides is a development status file name accordingly to the rawfile.
For me if i can write in the EXIF of the Jpeg/tiff or rawfile in that list of details some things like place and subject(s)
(date and such are already in there) that will be enough.
So why XMP then? eh i think the same reason as why using a DNG (not lineair).
In time it could be happening that the coding of a old specific rawfile can’t be read anymore and your image is lost in time. By decoding it in a general international container like Digital Negative Graphics its suppose to be accessible for ever.
So XMP is the DNG for the metadata of the image. (as far as i understand.)
Knowing this, yes if you build a DAM make it working with XMP-sidecars. Because it’s your archive for “livelong” managing images you can’t make again.
But as i understand building and maintaining this library cost computingpower which slows down the actual developement of groups of files. (Like to read every time again and again the hole index of a large booklibrary to got the indexnumbers of the shelf of the new books before you can walk to shelf with the latest books to see which one you like to read. That’s rather stupid if you know where that shelf is and you can walk directly to it because you bin there every month.)
It just slows you down unnecessary. But if you like to find that book you read years a go and you only know its a detective called Luke something and it was happening in Tokio around 1969, Yes then that slow index comes in handy.
So as i see a good working DAM.
- Automated indexing ónly when i want it to happen. (when i archive my rawfiles whom are worthy to keep. (that’s why i hated LR’s active folder “Stop doing things i didn’t ask you to!!!”
) - A DAM tab and a folderbased tab choise. (So i can choose if i want to search with TAGS and keywords or just jump to a folder i want to see.) And DAM-application is only running if the DAM tab is active.
- XMP seems to be read by all other applications the same so crossover to other applications and edit it elsewhere will update also in the original DAM. (This is crucial because you don’t want to do it twice or have different data in different tools/applications.)
- It has to be smart enough to overcome changes made outside the application without burning to much processingpower every time you start it up. And i think that’s a challenge to build.
So maybe DxO can build a DAM READER (XMP reader) inside DxO PL (so if you open a folder it reads only those XMP-sidecars and shows the information only when select a image) and make or use from a other DAM designer a DAMtool (editing XMP data) standalone.
Just keep images and sidecars connected wile moving around in the folders in DxO PL Organisor, so next time you start up the DAM it updates its indexlog.
Use the DAMtool to find and open folder or group with DxO PL organiser. or just don’t bother and open directly organisor and click on desired folder. 
2 Likes
Now that is communication 
This is all what was needed to sort things out. Thank you.
About the DAM: Please keep it optional.
1 Like
I don’t know what you mean by “actual developement of groups of files” but a DAM doesn’t slow down the work. Indexing files takes time, but searching is “immediate”.
Even Windows Search indexes image metadata and allows you to find a file as fast as you enter the search term.
Oliver
P.S.: XMP is not “the DNG for the metadata of the image”. It’s just the right place for metadata describing the image.
My experiance with opening PSE Organisor is every time it opens it starts to search for new changes(new images or lost one’s, try to reconnect the lost ones.)., this slowing down my initial reason to open the DAM. This is why i only use this DAM for my endproduct, image archive, so i this behaviour is as little as possible during my workflow.
If this behaviour is also at my start of workflow, by culling and adding and regrouping images and every start i have to wait until The DAM is up to date , that’s what i mean.
And second if this update cycle is running in the background does this slowdown batch developing? depends on the processor and memory i think.
xmp isn’t that de new default / standard for storing exif data and other metadata of certain files? In order to make a standard which any OS version and application can read even when we are in 2050 on win22? I mean dop files are DXO standard but not for Adobe. so its not transferable. and as far as i understand a xmp does.
like DNG format is a Standard.
In that i meant it is comparable. 
At least it is XML and lies outside of the native database. Even if you have to adapt the XMPs for the next tool, it is still possible. IMHO it is the best exchange format for metadata.
1 Like
that’s either bad design or wrong setup. In IMatch you can decide when to scan folder.
At least regarding metadata, you shouldn’t adapt the XMP files if you change the tool. Use tools and wirkflows conforming to standards (MWG).
Besides, I consider the XMP data being “native” and the database just a copy of it to enable faster access.
2 Likes
Yep, database is only there to lookup metadata fast, it can be disposed and recreated from the XMPs, at least concerning image metadata. What I meant with modifying XMP is, that there are application specific parts that are not defined by MWG. So to transfer for example hierarchical keywords from one software to another, adapting the XMPs is one possible way, if there is no explicit import from the source tool available:
stick with lr:hierarchicalSubject and trash ACDsee.
Most software uses lr:hierarchicalSubject but not acdsee:keywords.
To be sure, you might want to get more information in the ExifTool forum (where the metadata gurus are).
I am using ACDSee as my DAM now, like it much more than IMatch, and it is, how it preserves its hierarchical keywords, so no options there. But I know that lr:hierarchicalSubject is the most common tag name. So if I have to leave ACDSee at some time in the future, I will just make a global search and replace on XMPs, where I will replace the string “acdsee:keywords” by “lr:hierarchicalSubject”, so as if the keywords were set by Lightroom. The remaining structure is the same.
PhotoLab 2
I bought all versions starting with DxO OpticsPro 9
After using the trial version of PhotoLab 2 I did not update to this version for three reasons:
-
Aside from DAM, which I do not need, there seems to be only very little improvement. “Dehaze” is said to have improved, but I only see a tiny difference.
-
The NIK-collection has not been integrated. Am I supposed to switch to Lightroom to use it?
-
and biggest reason: DxO still does not support Fujifilm X cameras. If royalties are the reason, why do you do not name it and argue with that different sensor?
I hope you will do better in future.
From what I have read here Fuji X is a lost cause, so breath holding might not be a good idea 
Hello,
- No need, you can either use NIK collection as standalone app or export to any of the NIK plugins directly from PL (‘Export to application’ option).
Regards,
Svetlana G.
Despite what I wrote earlier about the cost I’ve just upgraded using the Black Friday 50% off deal. Go for it it won’t get better than that.
1 Like