Excellent Explanation of PL6 Working Color Space and Color Rendering

[zkarj (macOS, PLe+FP+VP, Pentax)]

@OXiDant

1 the image data as in “how do i read the bitmapfile correct?” I don’t know if any new camera has it’s own image coding but i suspect it does has small improvements and changes.
2 camera body specific exif/meta data which holds exposure to lightnes conversiondata, colorrenderingdata and other data which convert there rawfile into a OOC-jpeg.

3. How a specific sensor model (including filters used) reacts to different wavelengths of light. Much in the same way different films were known for their colour reproduction, or indeed some black and white films reacted differently to others.

[JoPoV]

So :

JPGs are saved with photolab in 4 different color spaces with embeded color profile. So those images should not contain any color out of their embeded color profile since photolab should convert them in their respective color profile when saving.

• on screen those 4 jpgs with embeded color profile look the same when viewed with XnView and epson application (which are color managed) but not with photolab.
  → Do color differences happen with out of screen gamut colors or with in screen gamut colors ? (second case could mean photolab color management is a complete failure).

• when printed from photolab with color managed by printer, prints look the same as when viewed in XnView and epson application.

• when printed from photolab with color managed by photolab they don’t look the same as when printed with color managed by printer.
  → Do in this case they look the same as when viewed in photolab ?

[JoPoV]

@Stenis

You are talking about what DXO might do when building a profile. I´m talking about that once they have let me in with my files I am totally free to apply any Canon, Fuji or Nikon profiles …

So you’re talking about loading RAW files in photolab (can’t apply camera profiles on demosaiced images).

@Stenis

Why don´t they just skip this nonsense blocking me from adding for example an A1 profile instead of the one lacking for A7 IV when that was new.

I think they need to build a camera profile to be able to read the raw file and then apply any other profile.
A little bit like changing an image color space needs a starting color space for this image to convert it in a target color space.
If the image has no color space, no way to convert it. You only can randomly apply a color space to it and hope it is the right one. But you’ll never know if the result is what was expected.
More than that, Raw format beeing manufacturer specific, and often camera specific, DxO has to do reverse engeenering to be able to read a raw file.

I think before testing camera (and so creating profile) photolab can’t read the raw file at all.
Because it would at best mean convert RAW to pixel image assigning “random” colors, and at worst being unable to read the raw file at all.
I think they need to run the testing process to know what to do with new camera raw files.

@Stenis

Didn´t you watch the video around 7:30 minutes or so? There they say exactly what I say here. Pick a profile of your liking if you don´t like the rendering your camera profile gives you.

I think that to pick an other profile, photolab needs to know base camera profile first to do a conversion.
If you could apply any profile on any not profiled camera and get right result, wouldn’t that mean that every sensor provide the same raw datas (even if RAW file is written in memory with different ways of coding) ? If so why need to profile camera for color rendering ?

@Stenis

it would have been handy when I was waiting 6 months for DXO to make a profile for my then new A7 IV. Instead I had to batch update and replace the model code in my A7 IV-files with the code from the predecessor A7 III.

I think your case is specific because RAWs of both cameras are similar.
But I think DxO needs to run the testing process to be sure about that. They can’t predict what camera manufacturers will do with any new camera.
And I don’t think listening to users who pretend a hack works can lead to DxO do something without having very scientifically verified it (and so run the camera testing process).

@Stenis

and believe me, I just could not see any difference at all from the A7 IV-files with the proper DXO profile.

So those 2 raws are very similar, but I think DxO can’t bet about what contains a raw format of a new camera but must scientifically test it to know.

It’s the same process as when a NEW os appears :
It takes time for this os and drivers to be really ok. Then it takes times for softwares to fully use this.
DxO makes more work than other demosaicer makers to profile cameras and lenses, so they are the last to provide new cameras integration in their software. But those tests are why you like photolab, isn’t it ?

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

I would be as fine with the A7 III profile or even with a profile for the 10 year old NEX 7 if I just got in at that time but DXO will not let anyone in without a matching profile. That´s why I used to batch update my A7 IV to AIII with a Hex Editor and a macrorecorder.

The A7 IV-profile was absolutely not crucial at all for me to develop a RAW properly and as we have seen in that video above DXO themselves in this video is recommending using the profiles of other cameras to gain artistic effects!!! It sounded almost as they used them like ordinary presets. It´s not more holy than that!

It´s just another rendering bias and a slightly different starting point but it is the lens profiles that are the really important ones and not the camera profiles.

[niecestanz]

I think Photoshop was poorly named and have never understood why people compare it with the likes of ON1, PhotoLab, Capture One etc. They wouldn’t compare it with Lightroom!..

[JoPoV]

@Stenis

my great surprise found that it is how I have configured my monitor, that determines what comes out of Photolab “Print”
…
when my monitor is set in sRGB Photolab Print will print all files in sRGB regardless of the embedded ICC in the files
…
Is the monitor set in P3 every file will be printed in P3 regardless of their embedded ICC-profiles
…

Is this a feature or a bug ?
No way to control this behavior ?
Is a color conversion done, or do colors go wrong when printing wit diffrent embeded profile than monitor set color space ?

[Wolfgang ([ Win10, PL+VP+FP, Nik7 / 3.3 ])]

@JoPoV

Is this a feature or a bug ?
No way to control this behavior ?
…

@Stenis is using a hardware calibrated monitor and when changing the monitor profile within Windows Color System (WCS) instead from the monitor hardware (or with the dedicated profile loader) most probably leads to trouble …

1. The current monitor profile, which is shown in WCS, is ‘read’ by all color managed apps.

2. Changing the profile at the monitor side – let’s say from AdobeRGB to sRGB – sets the monitor to those new values (= stored in the monitor) and forwards the change of the ICC profile to the WCS, so that the apps then get to know, “the monitor is in sRGB mode” – in some cases on the fly, otherwise after restarting the app.
   .
   The other way round doesn’t work. Simply changing the ICC profile in WCS does not trigger the hardware calibrated monitor. As a result the WCS communicates e.g. “sRGB” as system profile, but the monitor is still on “AdobeRGB” … then showing “wrong” colors – and easily to avoid.

If interested, please read here … / here …

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

@JoPoV

As I wrote:
When I calibrated my monitor, I did it in this order: sRGB, Adobe RGB and Display P3 (Display P3 is a tweak of DCI-P3 where a few parameters are set as for sRGB.

What happens in that Benq’s own calibration program Palette Master Element always updates Windows monitor ICM-file to correspond with the gamut of the monitor and that´s fine so far.

The problems occur when I switch between these three calibrations of the monitor that are stored inside the monitor’s so called LUT (Look Up Table). So, remember, P3 was the last calibration and then the ICM in Windows is for P3 too and that doesn´t change when I switch between the monitors profiles. So as Wolfgang writes all legacy applications that relies on that Windows ICM gets the wrong info and the colors gets rendered incorrectly by this.

There is no problem now for me when I know this. In order to just have one single calibration for both monitors and prints, I have decided to stop using Adobe RGB and sRGB at all. I now use P3 for all in order to get a possibility to standardise on just one ICC-type and that will cause too saturated images on sRGB-monitors, but a lot of displays are now using P3 (Apple monitors and phones) (or any other wider gamut like in Android and some TV-monitors as well that use REC.2020 for example), so there will always be unsatisfied viewers of my images on the net anyway - I just have to choose whom. Slowly?, sRGB is on its way out and quite a few new gamuts will compete about ho the new world will look on peoples monitors and phone displays.

So finally, when it comes now to handle a configurable application like XnView, it now works as it should, since I have changed its configuration to use Windows P3-ICM instead as default using the ICC inside the image files. There are other problems though that are application related because some of them defaults to sRGB and can´t be configured, others are not color managed at all. I now also save my JPEG-files consistently with just P3 from Photolab.

In fact, my printing in P3 looks really good too when printing using Canson Infinity Etching Rag-paper and Canson’s ICC for my Epson P900. When Adobe RGB is heavy on green and blue P3 is leaning more to red and it has been created because it better resembles what humans can see with their eyes.

I have learned even from rekommendations I have read at home here that it seems to be a common idea among quite a few photographers to set their cameras to save JPEG-files with Adobe RGB-ICC and since most images will be viewed on anything else than Adobe RGB, that never have been intended for use on the monitors in general out there on the net. Just for printing Adobe RGB makes sense. So, saving images by default in Adobe RGB might not be an all that good solution. For most people it would make more sense to save in sRGB or maybe P3 is you live more of your time in the Apple-sphere.

[noname (Captain Obvious)]

@Stenis

Palette Master Element

it is an old program - if you have more or less new BenQ monitor ( SW240, SW270C, SW271C, SW272U, SW272Q, SW321C ) then you want to use PMU, not PME

[Stenis (Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))]

I know but I can´t use the newer program. I have tried. We will see if Benq will fix that error. They ought to. Maybe this is low prio too since the monitor works fine with my converters. This is a problem for legacy applications relying on Windows ICM. Maybe they think the app developers have to adapt to the new realities - which they ought to too.

I think my modelcode was SW270B when I checked.

This is not a problem of high prio for me since it works för Photolab, XnView, Capture One and PhotoMechanic and my printing. That´s all I care about really in my everyday photo related usage of my computer. I have the knowledge now to avoid any of these problems after all the tests I have made. I have no problems now. Version 7 works fine too and I´m just about to upgrade from version 6.