Author Topic: Again about color space (+ BUG???)  (Read 3483 times)

nesys

  • Jr. Member
  • **
  • Posts: 17
Re: Again about color space (+ BUG???)
« Reply #15 on: January 05, 2018, 01:40:48 am »
Can you please confirm with DNG we can break out of AdobeRGB on TIFF export?

That would be a very good point, as a lot of threads online are saying DXO uses an internal AdobeRGB color space.

Do you know what changes are saved in a linear DNG, and what we need to modify after, for example, with CS6?

Thanks for your support

Andrea

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #16 on: January 05, 2018, 10:50:08 am »
I will try. Do not have any ACR based program anymore. Will try it with Affinity Photo. But reading this (year 2011, now 7 years ago):

http://forum.luminous-landscape.com/index.php?topic=54284.0

and ignoring the comments from support, it is almost the confirmation for:

1) TIFF colors are limitted to AdobeRGB in DxO. Selecting ProPhotoRGB as Custom Profile only marks the photo as such, but contains only AdobeRGB gamut.
2) DNGs are not limitted because no color space has been encoded

Looking at 1) and reading the following (ROMM RGB = ProPhoto RGB), I do not understand, why DxO limits the output gamut, while Lightroom produces 16Bit ProPhoto TIFFs with colors outside of AdobeRGB, even if I cannot see them on my sRGB monitor:

"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"

nesys

  • Jr. Member
  • **
  • Posts: 17
Re: Again about color space (+ BUG???)
« Reply #17 on: January 05, 2018, 11:04:17 am »
Point 1 is not enough to say DXO uses an internal AdobeRGB color space.

That is what they are saying in other threads.

What do you think?

Bencsi

  • Hero Member
  • *****
  • Posts: 1572
Re: Again about color space (+ BUG???)
« Reply #18 on: January 05, 2018, 11:25:09 am »
Hi Andrea,

 Just let me know, what is the purpose of using ProPhoto color space in the export rendering. I was involved in the large format printing business  10 years, employed by one of the market leader printer manufacture Roland. In our practice, the color space expansion was used AdobeRGB range max. The very sophisticated printout processes were able to cover the 90% of the AdobeRGB color space only. The FOGRA certificate usually prove the ability on a
specific printer model,
specific RIP software,
specific ink set,
specific paper only.
The wider ProPhoto color space was almost not available on normal printers. In our practice, the most delicate customers made an own paper ICC profile to get the best color fidelity. ( I do not mention RGB ->CMYK conversion, the age of the ink & age of the paper influence on the color quality. When we sold inks the lifespan of inks was 6 months, we have to annihilate after. ) You are right, the ICC profile selection has to fill its role in PhotoLab app. I'm just curious about the practical application of ProPhoto color space.

When I was a new DxO user also tried to change the color space, but finally resigned. Anyhow, the 99% of the monitors are able to display <90% of sRGB color space only, which represents ~70% AdobeRGB. The high color accuracy AdobeRGB capable monitors always using 10 bit color resolution and 16 bit LUT resolution - and cost significantly more. I use actually an IPS panel LG model. There are several other models having 10 bit color resolution, but I'm afraid it is not so common among DxO users.

Endre
« Last Edit: January 05, 2018, 12:12:31 pm by Bencsi »
Win7/64 PC, i7-3770, 3.9GHz, 24G RAM, Intel HD-4000 GPU, 27" calibrated LG monitor 1920*1080 px res. 82 DPI

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #19 on: January 05, 2018, 11:32:01 am »
Hm, difficult to say. It is obvious that there is enogh information to produce ProPhoto colors, because they can be derived from the exported DNG, as you have shown.

On the other hand, we do not know anything about the processing pipeline in DxO. It will be different for the DNG and TIFF paths. And whether the color space encoding happens at the beginning or at the end of the TIFF pipeline, desides whether an internal AdobeRGB color space is used or whether only the export part of the pipeline is to restrictive:

<RAW> -- <Step 1 - AdobeRGB from here?> -- <Step 2> -- ... -- <Export - Or here?> -- <TIFF>

I think, that if it would only be the export part at the end, we would see a build in "ProPhoto" option already, insitead of "Custom profile". Because selecting the profile in the export did not help, the encoding to AdobeRGB must happen in an an earlier step.

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #20 on: January 05, 2018, 11:38:26 am »
@Endre

I think it is less important for paper or monitor output. It is only needed for post processing in PS/Affinity when you start to shift and compress colors. The more different colors you preserve until this step, the more is the chance that two different colors are not rounded to one after transformation.

Bencsi

  • Hero Member
  • *****
  • Posts: 1572
Re: Again about color space (+ BUG???)
« Reply #21 on: January 05, 2018, 12:10:11 pm »
@Asser

I got it. For post processing the only way to keep the color resolution as wide as possible the DNG. It has no color space definition and all image data will be recorded in 16 bit. If you choose the TIFF format, there is Adobe RGB option, but let you know, the Adobe RGB is 8 bit wide only.

Endre
Win7/64 PC, i7-3770, 3.9GHz, 24G RAM, Intel HD-4000 GPU, 27" calibrated LG monitor 1920*1080 px res. 82 DPI

nesys

  • Jr. Member
  • **
  • Posts: 17
Re: Again about color space (+ BUG???)
« Reply #22 on: January 05, 2018, 12:23:39 pm »
@Endre,

I use a 10-bit monitor, I’ve also asked DXO to understand if PL is also compatible with this workflow, waiting for an answer. But maybe you can confirm.

@ All,

The purpose of my test is to verify if the internal color space used by DXO is wider than AdobeRGB or not. Because this should not be different based on export format. And people in other threads were saying DNG was useless because make no sense to use Prophoto after, in exporting DNG as TIFF, if the image was previously internally managed as AdobeRGB in the process from RAW to DNG...

This is true, but my test is saying something different.
« Last Edit: January 05, 2018, 12:29:28 pm by nesys »

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #23 on: January 05, 2018, 12:29:26 pm »
@Endre Then this is even worse. I do not like to use DNGs, because they do not look the same when moved between programs. And most programs even do not like to import linear DNGs.

What is needed is the possibility like in Lightroom, the preview in the RAW converter should match the output TIFF on the monitor. At the same time the 16bit TIFF should cover the ProPhoto gamut, so that Affinity/PS can work with the full color resolution.

What is the sense of having 16bit as selection, when an 8bit resolution is applied?
« Last Edit: January 05, 2018, 12:35:01 pm by Asser »

Bencsi

  • Hero Member
  • *****
  • Posts: 1572
Re: Again about color space (+ BUG???)
« Reply #24 on: January 05, 2018, 01:31:53 pm »
@Asser

 The target of photo editing should be a monitor or the printout. These are mostly using 8 bit resolution. If you are able to display on your 10 bit monitor a perfect image quality, the next user on another monitor certainly loose this quality. That was - and even get more common - reason to reduce the output resolution to any common display can show. ( It is similar to HiFi. The final music quality depends on some circumstance which is not predictable. The best recording on the best hardware should spoil the final quality in a reverberating room or far from the speakers.) The visual quality is influenced e.g. by the lighting environment. In a dark room you see something different than on free air during sun shine.
The internal processing of course must be more accurate than the final resolution. I think the 16 bit internal processing is far enough to make a fine job. The output of the processing should be 8-16 bit depends on the next step. Actually we have only 8 and 16 bit version.
As far as I know, PhotoLab is not supporting the 10 bit monitor resolution yet.

Endre
Win7/64 PC, i7-3770, 3.9GHz, 24G RAM, Intel HD-4000 GPU, 27" calibrated LG monitor 1920*1080 px res. 82 DPI

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #25 on: January 05, 2018, 02:00:38 pm »
Yes, ignore all other things at the moment. If I have the following case

RAW -> PL -> 16 Bit AdobeRGB TIFF -> AFPhoto -> 8bit sRGB JPEG

Are there advantages in the current implementation of PhotoLab over the following workflow?:

RAW -> PL -> 8 Bit AdobeRGB TIFF -> AFPhoto -> 8bit sRGB JPEG

I am asking, because in one of your last posts, it sounded like the resolution is 8 bit in any case for TIFF. Which would be a bad idea, because greater gamut on small resolution -> FAIL.

Basically I would like to work like with Lightroom. Stay in PL as long as possible without the need to think about color spaces. And when I do "Edit In > Affinity Photo" I would like to get the best possible TIFF which can be produced from my raw with as much information as possible. In LR I just configured 16bit ProPhoto RGB, and that was it. Again do not let me think :-)
« Last Edit: January 05, 2018, 02:18:07 pm by Asser »

Bencsi

  • Hero Member
  • *****
  • Posts: 1572
Re: Again about color space (+ BUG???)
« Reply #26 on: January 05, 2018, 02:47:59 pm »
The first transition workflow

RAW -> PL -> 16 Bit AdobeRGB TIFF -> AFPhoto -> 8bit sRGB JPEG

has better editing capability within the second image editor. That is an advantage - even the final file has 8 bit resolution only.
If your output media is capable to display the Adobe RGB color space ( 10 bit resolution monitor or Fogra certified printer ) you should send the 16 bit TIFF too. Keep in mind, the printers using a converter - called RIP software - to match the 4 color CMYK ( or 8 color C-LC-M-LM-Y-K-LK ) inks quality to cover the color space. Generally, the CMYK ( and 8 color C-LC-M-LM-Y-K-LK ) printers color space is rather close to sRGB than AdobeRGB.

Win7/64 PC, i7-3770, 3.9GHz, 24G RAM, Intel HD-4000 GPU, 27" calibrated LG monitor 1920*1080 px res. 82 DPI

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #27 on: January 05, 2018, 03:20:28 pm »
OK, then I missunderstood you in the upper post. I am consumer with a basic sRGB monitor and let my images be printed by a discounter. Really basic requirements. So my wokflows are:

RAW -> PL -> 8 Bit sRGB JPEG (98%)
RAW -> PL -> 16 Bit AdobeRGB TIFF -> AFPhoto -> 8bit sRGB JPEG (2%)

It would be great if PL would export 16 Bit ProPhotoRGB TIFFs to be on par with LR for the 2% case, to not introduce any sort of color clipping before the TIFF hits Affinity Photo. That was the only reason, I was committing to the discussion here. But it seems, that some parts in the underlying architecture do not allow it, so I will accept this. But I would understand, if this were an issue for a pro photographer.

nesys

  • Jr. Member
  • **
  • Posts: 17
Re: Again about color space (+ BUG???)
« Reply #28 on: January 05, 2018, 03:43:55 pm »
( It is similar to HiFi. The final music quality depends on some circumstance which is not predictable. The best recording on the best hardware should spoil the final quality in a reverberating room or far from the speakers.) The visual quality is influenced e.g. by the lighting environment. In a dark room you see something different than on free air during sun shine.

This is the reason why I have a lot of music in 24bit/192 or 92 khz, or DSD ... because the source needs to be the most accurate ... when you'll change your speakers you'll appreciate this. Of course speakers/room, as light for photos, are part of the equation ... but on the other hand when you'll be in a dark room you will be able to see something different ... otherwise you will lose the possibility (not considering that in the future we should have Prophoto monitors and/or printers, and if you have tons of Gigs of photos I don't think you will be keen to start the process from the beginning ... again)

As far as I know, PhotoLab is not supporting the 10 bit monitor resolution yet.

I hope they will implement this piece. PS is already ok, as C1 for example. And in Mac OSX we are now able to work with 10-bit workflow

Basically I would like to work like with Lightroom. Stay in PL as long as possible without the need to think about color spaces. And when I do "Edit In > Affinity Photo" I would like to get the best possible TIFF which can be produced from my raw with as much information as possible. In LR I just configured 16bit ProPhoto RGB, and that was it. Again do not let me think :-)

This is what I would like to achieve with my workflow:

1) Photo Mechanic to offload my image files, review, organise, add ratings and apply metadata

2a) RAW -> PL -> DNG for all photos in my storage

2b) RAW -> PL -> DNG -> CS6 -> 16bit Prophoto RGB TIFF portfolio to be printed

what I'm missing is a database solution (like Lr) :( I hope Photo Mechanic or PL will add this feature in the future

Andrea
« Last Edit: January 05, 2018, 03:51:24 pm by nesys »

Asser

  • Full Member
  • ***
  • Posts: 114
Re: Again about color space (+ BUG???)
« Reply #29 on: January 05, 2018, 03:53:02 pm »
My computer is Adobe free zone now. :-)

My database solution which partially covers 1) is IMatch. But it is only for windows, so no need to look this up.

 

photography