A quick guess might be that using Adobe RGB covers a larger colour space than sRGB and so is a halfway between those needing proRGB / CMYK and the rest of us who don’t?
I have not really had any issues working in PL2 and then moving to Luminar and Affinity where I use sRGB (which is what my monitor uses and is calibrated for. The professional printers I use also want images sent as sRGB too). I usually send them from PL2 through to other software as .dng or tiff files
Happy new year and sorry for not answering during the holidays.
If the input image is a RAW image, independently of the color space you selected in your camera, the raw input colors are neither in AdobeRGB nor in sRGB, but in the native color space of the sensor of your camera. In that case, PhotoLab converts the sensor colors to AdobeRGB and uses that as working color space. This cannot be configured. During export, you can choose between “as shot” (which converts to the color space you set on your camera) and converting to sRGB, AdobeRGB, or any other color space explicitly. Note that for AdobeRGB, no conversion takes place.
If the input image is an RGB image (typically JPEG), depending on the color space you selected in your camera, the input colors are in fact either sRGB or AdobeRGB. In that case, PhotoLab uses this color space as working color space. And again, this cannot be configured directly (only indirectly by converting the image to another color space using a 3rd party utility before opening it in PhotoLab). During export, “as shot” now means no conversion.
For display, you should use the color profile of your screen. I cannot find the option in Preferences --> Display --> Common on my Mac, so I suppose that the Mac version implicitly uses “Current profile of the display device”.
Thank you wolf. I only shoot RAW. Never jpeg. Still some questions, if you don’t mind:
Can a RAW file be in a “native colour space”?? I thought that a RAW file isn’t in any colour space at all (pure data…nothing else). Can it have one??
So , to say it simple:
import as RAW into Photolab …and PL shows images in AdobeRGB as working colour space?
if I select AdobeRGB for export (as maybe Jpeg), then all will stay in Adobe RGB
if I choose “as shot” for export, it also stays in AdobeRGB (because I imported as RAW). No difference with number 2 (selecting AdobeRGB).
you say, I can choose “any other color space explicitly”. Does that mean I can export as ProPhotoRGB? It’s hard to imagine going from a smaller to a larger colorspace. Maybe you mean, that I can export in any colourspace beside sRGB or AdobeRGB, as long as it is NOT larger / wider.
I think there’s no way to use ProPhoto at all inside Photolab in case of RAW files, Photolab “converts the sensor colors to AdobeRGB”, as you say. And: “this can not be configured”. That means…no ProPhotoRGB or any other larger colorspace than Adobe RGB.
I do not use Lightroom anymore, but only Affinity Photo occasionally. Much more export as finished jpeg or tiff.
Is the above correct? And can you please answer my questions?
Thank you very much!
The image sensor contains color filters, typically RGB ones. The exact nature of that red, green and blue depends on the chemicals used to make these filters, and it is slightly different for each camera manufacturer and camera model. That’s what I call “native color space of the camera”. It is not intended for display, it’s what the sensor “sees”.
Most cameras allow setting a color space in their settings, typically either sRGB or AdobeRGB. This setting impacts the JPEG images produced, but it does not impact the data in RAW files. The setting is still reported in the EXIF data of the RAW file.
When you import the RAW file into PhotoLab
– PhotoLab will apply demosaicking and convert the RGB values from the “native color space of the camera” into AdobeRGB.
– PhotoLab will apply any color adjustments (saturation, HSL, but also FilmPack color rendering if you happen to use that, etc.) in that color space. I call this “working color space” because it is the color space PhotoLab does most of its work in.
– To display the image in PhotoLab, PhotoLab will, after all other processing, convert the image into the color space of your screen.
If you select AdobeRGB for export, that last step will not take place, and everything will stay in AdobeRGB, as you say.
If you choose “as shot” for export, PhotoLab looks in the EXIF data of the RAW file whether you set AdobeRGB or sRGB in your camera settings and will either keep AdobeRGB or convert to sRGB.
Technically, you can choose any ICC color profile for export, including ProPhotoRGB. But as you say, doing so does not make much sense. The ProPhotoRGB export will only contain colors that already existed in AdobeRGB.
– I use this ICC color profile feature when preparing images for a printing service that provides ICC profiles (e.g. Picto).
– For post-processing the image in a 3rd party image editor (e.g. Affinity Photo, Adobe Photoshop), I recommend to stick to AdobeRGB as it contains all information that is available in PhotoLab and avoids additional conversions.
Indeed, it is currently impossible to get colors out of PhotoLab that are not contained in AdobeRGB. We are aware that this is a limitation, but frankly, there are not many colors in nature that do not fit inside AdobeRGB. If you encounter images that contain colors outside AdobeRGB, please share them so that we can raise the priority of this topic.
How about when I export the file as a linear DNG and then assign ProPhotoRGB in another raw converter?
Well, if the photographer likes saturated colours he/she might be tempted to use the Saturation slider that could easily push the colours outside Adobe RGB gamut. That’s why out-of-gamut warnings and softproofing are so useful, even if one uses a wide gamut monitor.
Thank you for your extensive answer, wolf. I learn a lot.
Is it difficult for DXO to implement out-of-gamut warnings and soft proofing in Photolab? (sankos mentioned this). Does this have the attention of DXO?
I’m really wondering why Prophoto was not chosen instead ? Of course, we do know that most output devices are unable to display all the colors of the Prophoto workspace. That’s not the problem. However, computations made in a wider color space and using 16-bit bit depth will be more accurate. Even if the data are eventually converted to a smaller color space at the end of the process (export, printing), it’s better to make the intermediary computations as accurate as possible. In any engineering computation, rounding should occur only at the end. It seems that DxO has chosen to make roundings at the very beginning of the process. This is surprising and unusual when comparing with other similar software.
I guess that using Prophoto or something like the Melissa RGB color space of Lightroom wouldn’t have caused any particular difficulty when developing DOP/DPL. DPL could have been a good opportunity to switch to a more “classical” choice. In the DOP era, I can’t remember having read clear statements about this with an exception in 2012 when a staff member wrote this very funny post :
En novembre 2012, Andy du support technique DxO écrivait ceci :
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. 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.
Obviously, he still had a lot to learn about color management.
Here is a nice visual from Bill Claff, who plotted a native camera gamut against sRGB, Adobe RGB and ProPhoto RGB. Out of the three only the latter fully encompasses the native camera gamut without the unnecessary clipping of raw data. Something like ProPhoto RGB or Rec2020 have pretty much become standard working colour spaces in raw converters for good reason.
Yes i agree on the maximum colorspace possibilities , you have to follow the standards to keep up with competition.
On the other hand each person needs to limit its workingspace according to its viewing device of it’s editingstation. Otherwise you adjusting in the blind outside the colorspace of the viewing device which can give strange effect’s when the cut off part’s are visualized again in printing profiles.
I am not experienced in handing over rawfile’s adjusted by me for printing. other then just sRGb one’s
i imaging that you deliver a jpg as end produced you created and the rawfile with the adjusting properties if posible and the printerguy’s check and adjust if necessary wile working on there calibrated highend monitors the rawfile in Prophoto-rgb before they print.
(it’s no use to deliver a file in a wider colorprofile which you can’t see in full. )
We’ve written and read a lot about colour space(s) and have not yet said anything about rendering intent. Rendering intent describes how colours that are outside of the display’s or printer’s gamut are rendered (mapped to the colours your device can reproduce). This greatly influences what you see on your display and your prints…
Anyway, DxO does what they do and we’ll have to live with it. Getting some information on how they do it, is a good start though.
Quoting Jean Delmas, our worldwide recognized color management specialist :
Une conversion d’image entre deux espaces de travail (et plus généralement entre deux profils V2 de type matriciel) ne connaît qu’un seul mode de rendu, le mode Colorimétrie relative . En effet, seuls les profils basés sur des tables contiennent les données définissant les autres modes de rendu.
The conversion of an image between two different color spaces (and more generally between 2 V2 matrix profiles) can only use relative colorimetric mode. Indeed, only table based profiles are embedding the data defining the other rendering intent modes.
Les espaces de travail RGB, sont de type matriciel. Ils ne contiennent donc qu’un seul jeu de données pour définir le comportement de l’appareil hypothétique dont ils décrivent le comportement (et non pas un jeu de données par mode de rendu comme c’est le cas pour les profils basés sur des tables). Avec sa malheureuse matrice des primaires RGB et ses trois « courbes gamma », un profil matriciel définit un seul mode de rendu, « son mode de rendu ». Ce mode est le mode Colorimétrie relative, le seul qui permette de calculer le mode Colorimétrie absolue, indispensable pour les opérations d’épreuvage. Mais, pour des raisons que je n’ai jamais vraiment élucidées, les logiciels d’étalonnages d’écrans et les procédures de fabrication d’espaces de travail, inscrivent souvent dans la métadonnée ad hoc la valeur erronée « Mode perception ». Il ne faut pas en tenir compte et seules les versions V4 des espaces de travail permettent d’appliquer le mode « Perception ».
Sorry, I must leave my desk now. If someone has enough time to translate…
RGB workspaces are matrix-based. They therefore contain only one data set to define the behavior of the hypothetical device whose behavior they describe (and not one data set per rendering mode as is the case for table-based profiles). With its unfortunate matrix of RGB primaries and its three “gamma curves”, a matrix profile defines a single rendering mode, “its rendering mode”. This mode is the relative Colorimetry mode, the only one that allows to calculate the absolute Colorimetry mode, essential for proofing operations. But, for reasons that I have never really clarified, screen calibration software and workspace manufacturing procedures often include the incorrect value “Perception Mode” in the ad hoc metadata. This should not be taken into account and only the V4 versions of the workspaces allow the “Perception” mode to be applied.