DxO Optics Pro / dng output / color

[fdisilvestro]

I would like to share some findings using DxO Optics Pro (DOP) with dng output. This would be useful if you like DOP optical corrections (distortion, lens softness, etc.) and prefer LR/ACR edits, especially for color (or you don´t have the new version of LR/ACR with optical corrections).

This is not intended to compare optical corrections between DOP and LR/ACR

 I have seen a few comments here and in other on-line forums about color issues with DOP, which could be summarized as:

- Output Tiff or Jpeg: Color spaces can be either sRGB or AdobeRGB1998. Even if you manually select another (like ProPhoto RGB) it will actually convert Adobe RGB to ProPhoto at the end, so you don´t gain anything. It is like opening the file in PS with AdobeRGB and converting to ProPhoto. This can be shown using gamut plots, but it is not the purpose of this post.

- Input other than Raw: If your input file is jpeg or tiff, DOP works only with sRGB. If you open a file in AdobeRGB it will "assign" (not "convert to") sRGB. This I consider as a big issue, especially if you planned of using DOP as an external editor to LR. Don´t use it that way.

The case with DNG output:

Are there advantages of using DNG output? for some time it has been argued the utility of such output over tiff, that it is not a raw file, etc.

After several test, I would say they are worthed if you plan to continue your processing in LR/ACR.

- Yes, they are not Raw, but demosaiced and interpolated files (linear dng)

- However, those files have not been color space encoded. When you open them in LR/ACR, you could still select a camera profile and white balance as in a Raw file

- A nice finding: The ColorChecker Passport software will accept a DOP dng, so you could generate a dng profile from it

- Since it has not been color space encoded, you could use the ProPhotoRGB space from LR/ACR

It is important to note that if you perform exposure adjustment or white balance correction in DOP, it will affect the dng file. This really matters if your raw file has any blown out area and plan to use recovery in LR/ACR. I´ll expand more about this later

Here are examples of the test:

The first image is a raw file (.NEF) processed in LR 2 with a dng profile created from the same image.

The second image is a raw file (.NEF) processed in DOP 6.5 only for optical corrections, output as dng. This dng has been used to create a dng profile with the X-Rite application and then the dng was processed in LR 2 using the dng profile previously generated.

Note: these first two images have been converted to sRGB for web viewing

The third image shows the areas that are outside AdobeRGB1998 (LR -> Tiff in ProphotoRGB -> PS gamut warning)

The fourth image shows the gamut plots. The one on the right side is the file that went through DXO. Both are compared to the AdobeRGB1998 colorspace (wire frame) to show an area outside of it in the yellow region. (These gamut plots have been generated with the tools in Argyll CMS and the Cortona 3D viewer)

[fdisilvestro]

DOP dng and blown out highlights, an unexpected finding:

I was trying to analyze how the dng output worked in terms of data modification. Using IRIS I found:

- Data is basically 15 bit
- Something curious happens with the blown out areas of the raw file: It uses the 16th bit, so some applications see this as a negative value (as IRIS)

To my surprise, LR/ACR have no problem with these 16 bits values, except there is a small caveat when using recovery: Adjusting white balance in LR/ACR will affect the tone of these blown out areas (they will not be neutral)

If you want the blown out areas to be neutral when applying recovery in LR/ACR, white balance has to be performed in DOP before the generation of the dng

Here are some images to illustrate this issue

The first image is the original Raw file (.NEF) in Rawnalize, showing the raw clipped areas

The second image is the DOP generated dng file in IRIS, showing the blown out areas black, since IRIS interprets this as negative values (the red dot indicates the measure from the blown out area as -23771, the yellow dot indicates a measure from a highlight (not blown out) of 28576) These values are an indication of the 15/16 bit values

The third image shows the case when white balance is corrected in LR/ACR and then recovery is applied for the blown out areas (the image has been darkened to emphasize the color cast)

The fourth image shows the case when white balance was performed in DOP and recovery is applied in LR/ACR. There is no detail, as expected, but the tone is neutral.

[MalcolmL]

"Output Tiff or Jpeg: Color spaces can be either sRGB or AdobeRGB1998. Even if you manually select another (like ProPhoto RGB) it will actually convert Adobe RGB to ProPhoto at the end, so you don´t gain anything"
Please clarify - did you really mean::

it will actually convert ProPhoto to  Adobe RGB at the end

Thanks
MalcolmL

[fdisilvestro]

To clarify:

If you select ProphotoRGB as the output space, the image will be encoded correctly in the ProphotoRGB space but it will not use the additional color space available in ProphotoRGB.

It is basically an AdobeRGB image converted to ProphotoRGB. Any color outside AdobeRGB will be lost.

It is the same as if you open an AdobeRGB image in Photoshop and then select Edit-> Convert to profile - > ProphotoRGB

[Ligament]

Is this still the case for DxO Optics Pro 7, that it will not output to true ProPhoto?

[Ligament]

Is this still the case for DxO Optics Pro 8, that it will not output to true ProPhoto?

[digitaldog]

It is basically an AdobeRGB image converted to ProphotoRGB. Any color outside AdobeRGB will be lost.

Makes me suspect all their processing is using Adobe RGB (1998) or some linear variant instead of ProPhoto (something Mr. Knoll thought about early on for ACR). I suppose re-enginnering this might be a lot of work.

If that's the case, why use ProPhoto as an option?

[deejjjaaaa]

Makes me suspect all their processing is using Adobe RGB (1998) or some linear variant instead of ProPhoto (something Mr. Knoll thought about early on for ACR). I suppose re-enginnering this might be a lot of work.

or may be they just do not see a need in a wasteful space like ProPhoto.

[digitaldog]

or may be they just do not see a need in a wasteful space like ProPhoto.

So that explains the option to use ProPhoto how?

[Ligament]

I asked this question directly to DXO themselves, and here is the answer:

Does DXO Optics Pro Elite output files in true Prophoto color space?

I have read on various forums that DXO Optic Pro will only output files in the sRGB or Adobe RGB color spaces, even if ProPhoto color space is selected in as the ICC profile. Is this the case? If yes, when will you offer true ProPhoto output?
Thank you, Jason
 

Bonjour Ligament,

What you have read on the various forums is incorrect. DxO will give you output files converted to ProPhoto color space if you wish it. However, you need to do a little more reading because a 16-bit TIFF file is not enough to hold all this information, much of it cannot be displayed on anything because it exceeds the capabity of human vision, and requires a 32-bit TIFF to hold it all.

We do not have 32-bit TIFF files yet, the best most expensive monitors cannot yet display the full Adobe RGB gamut, and some of the "colors" in the full Adobe RGB gamut are invisible to humans.

You can do this, but you will lose information rather than have something more accurate. See the attached.

Best Regards,

Andrew F.
Support & Assistance
 
Petr Vodnak Photography - Color Space.pdf

[fdisilvestro]

Hi,
I have not done the test with version 7. However, to clarify

What you have read on the various forums is incorrect. DxO will give you output files converted to ProPhoto color space if you wish it

Of course the files will be converted to ProPhoto, but it would be converting a file from AdobeRGB to Prophoto, so the encoding will be correct for Prophoto, but there would not be colors outside of the AdobeRGB space

a 16-bit TIFF file is not enough to hold all this information

This is the first time I have seen this claim, that 16 bits is not enough for ProPhoto RGB

some of the "colors" in the full Adobe RGB gamut are invisible to humans

Really? The primaries are visible to human, I can't see where are the invisible AdobeRGB colors

Finally, I would not recomment the article referred at the end of the messge.

[digitaldog]

Raw files with a gamut potential to be rendered and encoded outside Adobe RGB (1998) are easy to find. If this product, when instructed to produce ProPhoto RGB clips everything within Adobe RGB (1998), we'll know a lot more about what is happening behind the scenes. Anyone with this software, ColorThink and some raw's that at least in ACR/LR show gamut outside Adobe RGB should be able to test this.

[Ligament]

Raw files with a gamut potential to be rendered and encoded outside Adobe RGB (1998) are easy to find. If this product, when instructed to produce ProPhoto RGB clips everything within Adobe RGB (1998), we'll know a lot more about what is happening behind the scenes. Anyone with this software, ColorThink and some raw's that at least in ACR/LR show gamut outside Adobe RGB should be able to test this.

From DXO tech support:

"Bonjour Ligament.

DxO Optics Pro uses Adobe RGB as its internal working color space.

As I pointed out in my previous email, you need 32-bit TIFFs for Prophoto color space. Adobe RGB is about right for 16-bit TIFFs and 16-bit TIFFs are far too small for Prophoto RGB. 32-bit TIFFs do not exist yet.

A Nikon D800E is about high resolution not about capturing huge color spaces.

Did you read and understand the article that I sent you?

Best Regards,

Andy"

[digitaldog]

From DXO tech support:
As I pointed out in my previous email, you need 32-bit TIFFs for Prophoto color space. Adobe RGB is about right for 16-bit TIFFs and 16-bit TIFFs are far too small for Prophoto RGB. 32-bit TIFFs do not exist yet.

That's either a tech support person who's confused or is lying. It's a big pile of dog poop!

First, ProPhoto has been designed to work fine with 16-bit files, 32 bit is not required. In fact, since 1998, Photoshop users (and later, ACR and LR users) have processed using Prophoto RGB 16-bit data on what has to be tens of thousands if not millions of images (think about all the raw data passed through just those two Adobe products).

In one of, if not the original article on ROMM by Kodak, the white paper states:

The color space is also appropriate for archiving and/or interchanging rendered images. Both an 8-bit version, as well as a 12-bit version of this color space are defined.

and:

V. Conclusions
A new color space known as Reference Output Medium Metric RGB (ROMM RGB) has been defined. This color space is intended to be used for manipulation and/or interchange of images that exist in a rendered image state. Examples of manipulations that might be applied in this color space include manual color/density/contrast/tone scale adjustments, scene balance algorithms, red-eye correction, and dust/scratch removal. Both an 8-bit version as well as a 12-bit version of this color space are defined.

http://www.kodak.com/global/plugins/acrobat/en/professional/products/software/colorFlow/romm_rgb.pdf
Notice the date (1999)!

Further, the late Bruce Fraser did significant testing on ProPhoto RGB FOR Kodak and concluded that it was fine for use with 8-bit per color images but recommended high bit use. I'll see if I can dig up any emails from Bruce about this**.

The idea that one must use 32 bit files for ProPhoto is nonsense and further, IF what DXO says is true (it isn't), how on earth can they allow their users to convert into ProPhoto and worse, when the data is a smaller gamut, Adobe RGB (1998)?

DxO as a company needs to address this silliness from their tech support staff. We can't even now take his word that the processing space is Adobe RGB (1998) but I have suspected it was. So why allow a user to encode from that into ProPhoto? Why make up nonsense about ProPhoto having to be 32 bit yet let the products user do this FROM Adobe RGB? Maybe to make those who want a wider gamut raw processing space feel better.

Where might we find DxO's white paper about ProPhoto RGB having to be used with 32 bit data?

**Also from the Kodak white paper:

Bit Depth for ROMM RGB Working Space
An important consideration relative to the “editability” of an image in the ROMM RGB Working Space is the bit depth. RGB Working Spaces in the Photoshop software offer both 8-bit and 16-bit modes. (As discussed above, it is generally recommended that ROMM12 RGB images be converted to a 16-bit encoding when stored in a file that is to be read into Adobe Photoshop software.) Where possible, the 16-bit Working Space should be maintained in the Photoshop software for the manipulation of ROMM16 RGB images. In some cases it will be desirable to use the 16-bit Working Space option even for the manipulation of ROMM8 RGB images. This makes it possible to apply more aggressive image adjustments to an image with the minimal introduction of artifacts. The recommended approach for the most discerning color imaging professional is to make all major color appearance adjustments while in 16-bit ROMM RGB Working Space, then only drop back to 8-bit for any final fine tuning and specific “output preparation” adjustments.
Kodak, ColorFlow, PHOTO CD and PhotoYCC are trademarks of Eastman Kodak Company

[deejjjaaaa]

So that explains the option to use ProPhoto how?

it is just an output "container" for narrower data by popular demand from people who do not know about tighter spaces... in any case DxO caters to its audience which apparently does not include people who are missing colors outside of AdobeRGB in their final result (print or display)... the same is for SilkyPix (output wise at least) - only AdobeRGB and sRGB are offered

[deejjjaaaa]

DxO as a company needs to address this silliness from their tech support staff.

it is not going to happen... the only way not to have "silliness" is to have actual developers (and not tier 1 support) answering (like for example Eric Chan does), otherwise you can always get incorrect information about how things implemented...

[digitaldog]

it is not going to happen... the only way not to have "silliness" is to have actual developers (and not tier 1 support) answering (like for example Eric Chan does), otherwise you can always get incorrect information about how things implemented...

And/or have customers bitch like hell when they hear this stuff. Keep in mind, LuLa gets something like 1 million unique hits a month. This is the place to air out that smelly vendor laundry.

If they want to say "look, we use Adobe RGB (1998) for processing and that's the gamut limit" fine. Just don't lie and post a lot of dog poop about a working space that is been used for 13+ years.

[RFPhotography]

it is just an output "container" for narrower data by popular demand from people who do not know about tighter spaces... in any case DxO caters to its audience which apparently does not include people who are missing colors outside of AdobeRGB in their final result (print or display)... the same is for SilkyPix (output wise at least) - only AdobeRGB and sRGB are offered

Or who don't know they're missing those colours.  I suspect not all DxO users fit into either category though.  As Andrew said digital raw files can capture more than the ProPhoto space.  There are printers that can render more than AdobeRGB in some colours.  DxO's advice is wrong and their clipping of colours even when optionally trying to output a file tagged with ProPhoto is bad programming.

Further, their comment that nothing more than AdobeRGB is needed because monitors can't reproduce it is ridiculous.  Monitors today may not be able to reproduce more than, or even as much as, AdobeRGB but who knows what the future will bring.  A few years ago we had to be satisfied with monitors that could only reproduce sRGB.  Same with printers and papers.  If nothing else, using ProPhoto is future-proofing.  Why go back and have to reprocess hundreds, thousands or 10s of thousands of RAW files to take advantage of display/printing advancements in the future?

[Ligament]

I would encourage you all to email DXO labs and make your complaints and arguments against using adobe RGB as the internal working color space.

It is a great software otherwise; to limit the color range on purpose is self defeating.

[digitaldog]

in any case DxO caters to its audience apparently does not include people who are missing colors outside of AdobeRGB in their final result (print or display)... the same is for SilkyPix (output wise at least) - only AdobeRGB and sRGB are offered

How would they know otherwise?

How do you know about the market or the aim of which DxO caters?