In the first post, the RAW development uses ROMM RGB and then converts the developed image to LAB color space as a pixel image. Best to watch the video in its entirety.
Now when I finish processing the image and give that to print, yes I will output that in sRGB which is much smaller than LAB.
I am not yet quite clear whether this really brings me much, and whether and how I can use the handling also in DXO.
Maybe someone has already had experience with this and can shed some light on the subject.
Converting an image to lab color or working in lab color space allows you greater flexibility manipulating colors and light in an image. The video you linked, gives a good example of one way to use lab color. Sometimes an image will need the colors to “pop” a little more and using lab color is a way to do this without making the image look unnatural. I don’t believe DXO has a lab color space option.
PhotoLab’s internal color space is Adobe RGB. So no working with anything larger here. However, there is an open feature request to add support for larger color gamuts like Lab or ProPhoto.
That’s actually some pretty interesting piece of info.
So you actually make use of an OS independent, internally developed color management system?
I have a background in CMS in the print industry – our world is LAB; interpreted by a host of different color management engines.
Well yes, PL’s internal workspace is AdobeRGB
(instead of ProPhoto, ROMM RGB from AP or MelissaRGB from LR)
and set like
makes use of the current display device profile.
With that, a screen capable (or set) to render sRGB colour space displays the correct colour
(within its limits), but the file’s colour space (e.g. AdobeRGB) is not affected.
As said before, PL does not support Lab color space.
In Lab colour space → https://www.xrite.com/de/blog/lab-color-space
the Lightness “L” is separately handled from the colour,
which is represented by “a” for Green (-) → Red (+) and “b” for Blue (-) → Yellow (+) values.
Like this, several programs (AP, PS …) e.g. allow to only sharpen the Lightness information
and adjust the colour(s) separately, the colours without being affected by a contrast curve
OR equalizing colour & softening colour noise without affecting the sharpness / texture (the information from the Lightness channel) OR …
in general (short version !)
editing should be done with a 16bit file to avoid (reduce) tonal breakdown
exporting for web should be done into sRGB colour space
avoiding / reducing problems with the colour renditon
(untagged files are quite often handled as sRGB)
the appropriate colour space for printing depends on
if you print yourself → sRGB / AdobeRGB / 8bit / 16bit
the service provider’s information, commonly → sRGB
from a somewhat brutal but true saying:
“When you dont’t know (better), keep with sRGB.”
Many of the monitors in general use are not able to display even the full Adobe RGB gamut let alone the Kodak ProPhoto(=ROMM) gamut or the LAB-space that extends, in principle, to every hue that the human eye can distinguish (but in reality only 10% or so more colors than the ProPhoto space).
So ADOBE RGB is probably sufficient for current RAW processors. There is still an argument for using ProPhoto to represent hues that can be reproduced in some media but that lie outside the ADOBE RGB gamut. That is why I save all my images out of PL5 using a ROMM-RGB profile in the export dialog.
Inkjet printers are, of course, still more limited in the gamut they can reproduce but it’s typically not orthogonal with any of the foregoing gamuts: the hard question is how to fill their potential gamut with the best translation from the editing workspace (a discussion for elsewhere).
I think the main advantage of working in a LAB workspace (which I would REALLY like DXO to provide, but I’m not holding my breath) is that it makes it possible to work with development tools in a luminance-only (‘L’) channel mode. This can be invaluable for e.g. curves adjustments. I REALLY would like to see this in PhotoLab and I note it would FIT THE NAME of the product. A secondary advantage is that it makes color-contrast a target/tool of development rather than – as it is now – a hard-to-predict effect of general contrast tools (e.g. “Selective Contrast” in PL) that affect RGB color contrasts indirectly in a much less transparent or accurate manner.
In the absence of a LAB workspace, however, I’d also be very glad to have a Luminance-only channel for the Tone Curves tool.
