Partial solution to work with DeepPRIME in PhotoLab's main viewer

i can see this as a big advantage for professional photo editors:
use a dedicated pc for digesting RAWfiles push it throug DXOPLv4
create DNG’s on a shared folder/cloud/ server and use that as startingpoint for editing and developing.
storagespace is then much less an issue then at home.

Archive the Rawfile’s on a different offline storage in case of disaster.

For me as a few image’s a month and one by one developing route is DNG mostly storage filling extra file with no meaning for me unless i use it as transport container to an extra program.

But still i like that “floating WB” it has now. i can export and use the second application which treat it as a “cleaned rawfile”. :sunglasses:


Never !
…if you would like your picture to benefit from DeepDeepPrime one day :nerd_face:

Storage costs less and less everyday. Except if you want full SSD…
But I agree with your post. Great news for big projects.

1 Like

What about The AbyssPrime, endless deep denoising? :grinning:

1 Like

I am afraid this will use endless computer ressources :upside_down_face:

1 Like

Isn’t this the answers you are looking for ?

I’m not likely to need this feature except perhaps occasionally but it’s a great option to have.

One question I have. If I export such a DNG file, what attributes does it have? Will Lightroom still see it as coming from my camera? Or is it in some bespoke DNG sub-format? And what about the meta-data?

I’m trying to understand if I push a camera-created DNG through PL4 and then on somewhere else, what is missing/different (apart from the great processing) compared to the original?

You could push an image through the intended workflow, export metadata after each step and compare the exported metadata files. This would exactly show what your case will do.

Update: Just checked metadata of an original Canon .cr2 file against metadata in .dng files written by Adobe DNG Converter 13 an DxO PhotoLab 4. I found that .dng metadata entries differ from metadata found in the .cr2 file. It was just a quick test, but looking into different sections reveals differences that might or might not be relevant, be it now or later.
Anyway, I’ll stick to my original files and work with them rather than with DNG copies.

This is another new feature from PL4 lacking some communication, and I guess that’s because it’s not a simple one to explain. So, a few steps back before explaining it. DNG files include metadata that describes how to interpret colors - I mean how to translate from the pixel values in sensor color space into a standard color space (what we call applying color rendering, as a side note this color information embedded in DNG file looks like what you got in a DCP file - DNG Color Profile). Until PhotoLab 4, color rendering options did not offer the choice to use this embedded DNG metadata to do the color rendering (choices offered were to apply a precalibrated color rendering, or to use another file like an ICC file or DCP file). With PL4, this option to do color rendering based on DNG embedded color data has been added, and that’s what you are seeing right now (on top of every other color rendering options that are usually available on RAW files). So to answer to your question, what happens if in your specific case (you reprocess a DNG file outputted by PL in the first place, and you apply on it “Generic renderings\DNG embedded rendering”): PL will use embedded DNG metadata to do the color rendering as explained above, which turns out in that specific case to obtain a color rendering close to … the one you would get by default in Lightroom or Adobe Camera RAW! Why does PL embed DNG color data than matches Lr/ACR colors instead of the one applied in PL? Choice have been made years ago to embed metadata that tries to fit Lightroom/Adobe Camera RAW colors, because this DNG export was mostly designed to integrate smoothly OpticsPro/PhotoLab in a workflow including Lr/ACR. Of course, if you don’t care about Lr/ACR color rendering, you still got the possibility to select any other color rendering when you process a DNG file that is the result of a PL export.


On top of having applied denoising and lens corrections inside this exported DNG (I still speak using option “Export as DNG (denoising & optical correction only)”), main difference is that in exported DNG file by PhotoLab, we include XMP metadata that tells to Lr/Adobe Camera RAW to not apply by default it’s own denoising and sharpening (as we assume it has been done on PhotoLab side, it would be bad doing it on both sides: picture would be over corrected). But these settings on Lr/ACR side still can be changed manually if you like.

1 Like

Just to clarify, color rendering applied during RAW conversion and color space used to export a file are rather independent things. Color rendering deals with how your color will look, and color space at export defines the referential used to describe such colors when you export the file. So yes, as long as you output your DNG file in tiff or JPG, the possibility to select color space used for output (including ProPhoto) will be available.

Does this mean that an other developer application NOT pickup this flag and also does his optical correction and such again?

1 Like

Most probably yes if the competitor used applies some sharpening or lens corrections by default: in such a case, they should be manually removed.

1 Like

Is this testable? like an image of a 15mm prime wide angled shot of a doorframe or such?
(And if denoise is twice done like the second does a action over it does this harm deepprimes action?
i think no noise means no action of a denoise engine.
And the second denoise can’t hurt either IF it doesn’t ruin the earlier denoise action.

This is tremendously useful! I will definitely put this to work. Thanks for adding this feature and bringing it to our attention.

I’m experiencing a weird color difference when processing a blown sky between the RAW file and the DNG file(with optics corrections and denoise only). It is my understanding that the color rendering should be the same with both, no?

Here is what I get when processing the RAW file:

And here is what I get when processing the DNG file identically:

The sky turns an ugly pink and green. I was using a gradient mask on each one to recover the highlights in the sky in addition to exposure compensation. I don’t know what to think. The sky is not too blown to be recovered as the processing on the RAW file shows. @Benoit any ideas?

Indeed, this is bad, and this looks like our legacy DNG export option “Export as DNG (all corrections applied)” (on which everything was applied, which leads to destructive color management). Are you sure you exported in DNG using output option named “DNG\Action\Export as DNG (Denoise & Optical corrections only)”?

Yes, absolutely certain.

OK. Would you mind providing us your RAW file (the original CR3 file) + .dop file so that we investigate this?

You can upload your files to our file server at the following URL:

Please, fill in all the fields.
In “Support ticket number” field you should write your Forum User Name. Please advise in your reply in this thread to confirm that the files are available on our server.

Thanks a lot for your help.

It also need some time to understand every detail :joy:
But those are precious informations and your business to bring great quality into our picture. You definitely should have an article on your blog or knowledgebase.
Make some noise for Deepprime and this new dng export :crossed_fingers:t4:

1 Like

Okay I’ve uploaded the original CR3, it’s DOP, the DNG and it’s DOP. A little background: Svetlana already has this file. I already had a problem with this file.
Possibly this file is somehow corrupted but thought that @Benoit and the team should investigate.