I’m not sure what you are getting at here. PL only creates a bitmapped image when you export to JPEG or TIFF, whilst leaving the RAW file untouched and there is no need to keep the bitmapped image on disk as a separate file, once used, because you can reproduce it at any time by simply re-exporting it. What is more, the DOP file can contain multiple versions of the image in a very small file, so you are free to experiment without having to fill your disk with multiple large bitmap files. If you want to revert to the original RAW image, all you need to do is create a new virtual copy and reset it or, as I do, always keep the untouched master, only ever working on virtual copies.
1 Like
I was referring to the capacity of LR to make an HDR or Panoramic image from several input images and keep the result as a DNG file (with a raw version ‘embedded’) along-side the original raw images or (alternately) to export a ‘SmartObjects’ (each with an embedded raw file) to PS for further processing. The advantage of either approach over the creation of a TIFF file by export from e.g. DXO is that you retain the raw-image’s data & ‘plasticity’ (whereas a TIFF is a bitmapped instance of a ‘frozen’ derivative of the raw image). As you know, the only way to create a Pano or HDR based on DXO’s raw-processing is to export such ‘frozen’ TIFF files for external combination into another bitmapped file.
I suggested that this capacity LR to retain the raw data after processing (e.g. to HDR or Panorama) is an advantage. Of course, when you create a LR HDR (DNG) or Panorama (DNG) in addition to the original raw file, and when you export a ‘SmartObject’ from LR you are creating a second, rather large, image file that is referenced in your LR catalog. But I’ve stopped worrying much about (local) storage capacity. More important to me is having the flexibility that a raw file offers up to the point of final output (for screen or print).
Still, I think this is a ‘nice-to-have’ advantage of the Adobe suite: it has not dissuaded me from adopting DXO PL as my preferred processor.
While true, it is not possible to rename those virtual copies (add something descriptive to the end of the file name) to keep track what they are meant for. – Returning later, I don’t remember the reason for the said version.
…add keywords and you’re fine…
1 Like
Yes, I was thinking about this – I’ll see, if this is a viable solution for me.
[ see → Sharpening with PL4 - #6 by Wolfgang → the section about printing ]
It’s the only option right now - unless you export the VCs under different names.
VCs only exist in PhotoLab’s database and the .dop files. They eat no drive space like physical copies, which can bear individual names though.
DPL4 sidecars contain the necessary info about VCs, but no keywords yet.
The first VC is highlighted in blue in the screenshot below.
1 Like
Peter, as far as I am aware, when LR processes a panorama or HDR and saves the result in a DNG file it is no longer RAW. The individual files have been demosaiced and combined to create a new bitmap file which is stored in the DNG file. A DNG file is just a wrapper that can store anything from a true RAW file to a TIF and even contain an original RAW file for archiving. A lot of people make the mistake in believing that all DNG files contain RAW data. This is not necessarily the case.
3 Likes
Yes, I know that’s true of the DNG wrapper. I hadn’t considered that might be how the recombination is done in LR. I was assuming it was akin to a “smart object”. If it’s only combined bitmapped data then there’s not much advantage over an external TIFF file.
Still, what you say makes sense; thanks, Keith. I guess it would be possible to check (if it were worth the effort 🤷). But it’s not, to me, anyway. So I withdraw my claim of a LR advantage on this score. 
Keith is correct the HDR/Pano in LR is simply a Tif in a DNG container. Adobe are vague on this because many people believe that they have an end to end workflow. Provides a marketing advantage to Adobe.
1 Like
Well Alec, it seems DXO is on schedule and lanches version 5 in October as usual and besides the unexpected support for Fuji it seems they have put in the most of it’s efforts to develop the Photo Library. It now supports IPTC and have got some metadata batching tools that seems pretty effective besides a far better metadata exchange with Lightroom and hopfully even PM Plus.
Since it now seems to read and display all(?) IPTC-elements in the XMP-files and hopefully the metadata in the headers of JPEG, DNG and TIFF I have to download Photolab 5 to see if it displays all my metadata from Photo Mechanic Plus. If it does it will be a good leap forward. I didn´t really see this coming so soon but at least it looks like it can work.
To Peter G:
I also saw a few welcome improvements of the U-point tools and layers. We have got a Chroma-slider and a linear mask tool too for better control and precision 
- but no AI what I could see.
Alec, quote from your text:
DAM and metadata in some ways is over-rated. If one is not shooting for stock or running a photo studio, arranging one’s images by data in a consistent folder structure with RAW images and finished images takes one a long way towards DAM. Just naming the folders well solves most issues with finding events. Dropping a text file in the folder with more detailed notes makes those images even more findable. And all of this comes for free with your OS, whether Windows, Mac or Linux.
…Carl Seibert who has worked with DAM for decades feels PhotoMechanic Plus is the first real affordable DAM for photographers ." (end of quote)
Finally I found a thing to really disagree with you:-). I have no images at Stock and no studio but 70 000 images despite I don´t take images to sell and I must say PM Plus really has changed my photolife. I never could justify the time I had to spend with the inefficient library in Lightroom to get the job done to tag my images BUT in a far more efficient tool like PM Plus it suddenly was doable. I had a functional folder structure to begin with and a namingstructure on files that works and that helped a lot to get started with the metadata tagging.
After a year I have a library that isn´t fully complete when it comes to the metadata but it´s really working and finally I feel it has been worth it. I have never before had so many possibilities to cross search my metadata for themes I think are intresting and that has changed my image archive from being a never ending headache and a deep source of irritation to a real source of joy. For the first time I´m in control of my former mess.
I knew what to expect because I have seen what an enterprise DAM can do for earlier chaotic organisations and the difference between my mess and the mess in big organisations and enterprises, lost between their big piles of uncontrollable info silos, is mainly the scale.
Thanks för the link to Seiberts review of PM Plus 6. It was really good and I picked up a few things I didn´t know before.
1 Like
Stenis, please let us know how you get on with your Photo Mechanic metadata test.
1 Like
Antoine, I have now bought the upgrades of Photolab 5 and Filmpack 6. It wasn´t so bad the price. 128 Euro for both programs.
I have just made my first tests of the new IPTC-metadata support in Photo Library and it looks surprisingly good so far. They have now even a checkbox in the “Export to disk” dialog, if you don´t want to export the IPTC-metadata.
From what I can see Photolab manages to read and display nearly all the IPTC-elements correctly both from ARW XMP-sidecars and embedded metadata in JPEG- and TIFF-files. The elements it didn´t fix are the ones under IPTC Image (location data). I have to look in to that a little bit deeper. In PM Plus there are a couple of different location info sets and I might have used the ones Photolab doesn´t support. So of that reason it looks like it supports quite a few IPTC-elements but not all but for most people the support now seems more than enough. I will try to update these elements in Photolab and look in PM Plus where that data travels.
One thing to notice though is that metadata won´t get duplicated when you make a virtual copy of a RAW. That is something to be aware of when exporting a JPEG from it.
The keyword-function supports hierarchies of keywords too, in a quite smart fashion too.
That´s all for now.
1 Like
Each Virtual copy can have it’s own metadata which is stored in the .dop file. This may be why new virtual copies do not contain the master’s data but you can easily copy the metadata from the master to the virtual copy.
Many thanks Stenis for that comprehensive note of your testing, it is very helpful to know.
Sorry Keith I was wrong! PL5 is in fact transfering the metadata from the RAW-master to the virtual copy without me having to use copy-paste. The reason to my confusion is old sins. I might have made the virtual copies before the master had got any metadata years ago.
Despite that I think the metadata copy-paste-batch tool will be good enough to manage metadata in an efficient way if the user is using PL5 Photo Library as their image archive. I prefer a solution like the one in Photolab before the one in Lightroom with all it´s pre-made inflexible metadata forms.
I´m a little surprised myself but I think Photo Library will be fine for a lot of people as it is but I have to mention one thing they have to fix. Yesterday night I used the “Index a folder”-funktion that is supposed to read the XMP from the files and update the database. As i Photo Mechanic you just select the topfolder in your folder hierarchy and start indexing if the intension is to sync all of the files XMP-metadata with PL. Since I have tousands of files it took some time but there is nothing like in Photo Mechanic that gives you feed back on how the job is proceeding and how long it´s expected to take before it´s done.
Anyway the Photolab Photo Library it´s surprisingly good being an 1.0 attempt. When looking back to the last year when Photo Mechanic was released we have got numerous updates with a lot of fixes for issues with that software. The Photo Mechanic catalog solution was 1.0 too a year ago. Of course PM Plus is a much more complicated software than PL5 Photo Library is and most of the issues hasn´t affected me but some really has. It would be unrealistic to expect Photolab Photo Library 1.0 to be completely free from flaws.
1 Like
This thread has been really interesting and I suddenly appreciate how much I still need to learn. I left Adobe the day they started the subscription only option as I did not want to be locked in on something and when I stopped paying I lost the ability to use a tool I had paid so much for. Anyway, I also found DXO gave me better results so I was immediately hooked on DXO.
My workflow is importing using FastRawViewer to cull and sort. Then I copy the files I want into IMatch which I use as my DAM software to add keywords to the RAW files and rate as needed. From there I use DXO to process as well as Nik and once done I save a jpeg copy that I can then share with others. No issues until I upgraded to DP5. Now when I get the jpeg back the entire keyword structure is pulled apart and I now have both the parent and sibling keyword visible and saved as two keywords so the structure has been broken and I need to correct it after each processed photo. I hope they get that right otherwise there will be a lot of us that are very unhappy.
As an aside I use Hugin Panorama for stitching photos and Photomatix for HDR. If anything I would prefer DXO having these functions rather than spending money on a photo management tool.
Hello @akirstein,
Could you, please, provide us with the image + xmp from IMatch (with keywords applied) and the jpg you’ve got.
Please, upload them here - upload.dxo.com with your forum name and let me know when ready. We will investigate the issue.
Thank you
Regards,
Svetlana G.
Hi Svetlana
Thank you for looking into this. I have sent the RAW file and attached XMP folder. I have also sent the tiff file after processing and then the final jpeg (_DxO). I have also included the jpeg (no _DxO) which I needed to clean up. Also attached is a screen shot from IMatch that shows after importing the tiff and jpeg (_DxO) I now have new parent keywords (TYPE, WEATHER, WILDLIFE) at the bottom of the list with the original TYPE still sitting under the ARCHITECTURAL & STRUCTURE parent folder.
I think what is happening is the hierarchal structure seems to be flattened in DxO which is not what I want. I really hope you can help as this is a major and will be for many who use IMatch.
With thanks
Andre
Thank you for the files. We’ll investigate the issue.
Regards,
Svetlana G.
I had already mentioned the problem, in fact PL5 takes the parent keywords as a keyword when they are only there to make a hierarchy.
It would be necessary to have the choice to consider the parent keywords as a keyword or not.