Colour Management Problem with Firefox

[pschlute]

The two images should look very different when viewed on a wide gamut monitor. If they dont then there is a problem with your browser or monitor profile or both

[xpatUSA]

The two images should look very different. If they don't then there is a problem with your browser or monitor profile or both.

They look the same in FireFox 98.0.2, the icons look the same on my desktop, thumbnails and review images are the same in both XnView and FastStone Viewer.

I very much doubt that means that I am the one with a problem ...

... time for y'all to dump Win 10 or 11 and Adobe too ...

[pschlute]

They look the same in FireFox 98.0.2, the icons look the same on my desktop, thumbnails and review images are the same in both XnView and FastStone Viewer.

I very much doubt that means that I am the one with a problem ...

... time for y'all to dump Win 10 or 11 and Adobe too ...

They will look the same on your desktop or in previews in a folder, or thumbnails or in FastStone.

Even windows 10 is not a colour managed OS, let alone win7

If you want to look at them correctly you need to use a colour managed application, correctly set up, preferably with a wide gamut monitor.

Time to take the blinkers off Ted

[xpatUSA]

They will look the same on your desktop or in previews in a folder, or thumbnails or in FastStone.

And in your posts and also opened locally in FireFox 98.0.2 they also look the same. Is my FireFox different to yours somehow?

Even windows 10 is not a colour managed OS, let alone win7
If you want to look at them correctly you need to use a colour managed application, correctly set up, preferably with a wide gamut monitor.

Time to take the blinkers off Ted

Not nice.

Which of these applications are color-managed:

GIMP 2.10.8
IrfanView
RawTherapee
XnView
PhotoMechanic
ImageJ aka Fiji

If you say "none of them", that could lose you a bit of cred ...

[pschlute]

So Ted, you are telling me that a 255 red in ProPhoto and sRGB should look the same ?

If that were the case, what is the point of a wider gammut than sRGB ?

[xpatUSA]

So Ted, you are telling me that a 255 red in ProPhoto and sRGB should look the same ?

NO. I have told us several times that a 255 red in sRGB and a 179 red in ProPhoto should look the same. I also mentioned that a 255 red in ProPhoto can NOT be converted to sRGB without gamut clipping.

If that were the case, what is the point of a wider [gamut] than sRGB?

Straw Man alert!

More to the point, and since you're not telling me which of my apps are color-managed, I did look at your last example posts - the which made me quite glad to live outside the pale of Adobe and wide-gamut monitors.

The red RGB values in each of your examples are virtually the same which is NOT how profiling works in the Real World and indeed explains why they look different in your system and why that is wrong.

I'm done, Peter, I'll leave the coveted Last Word to you ...

[pschlute]

No. I have told us several times that a 255 red in sRGB and a 179 red in ProPhoto should look the same.

Agreed...

and therefore a 255 red in sRGB and a 255 red in ProPhoto cannot look the same. Which is why I do not understand your next point:

The red RGB values in each of your examples are virtually the same which is NOT how profiling works and indeed explains why they look different in your system and why that is wrong.

My two examples both have 255 red values, one is sRGB and one is ProPhoto, and that is why the DO look different when viewed in a colour managed application on a wide gamut monitor.

[DanK]

if you are looking at these images on a wide gamut monitor you will see more difference between the two than if you view on a sRGB monitor, but the difference should be present on both

Doesn't seem to be.

When I set my wide-gamut monitor to sRGB, the two images indeed still looked different. But when I checked on a narrow-gamut sRGB monitor, they looked identical.

The latter makes sense to me. Converting the image to sRGB in Photoshop and converting it to sRGB to display on an sRGB monitor both require shrinking the gamut to the same size. It's a bit surprising that the alorithm for doing it isn't appreciably different, but it should be very similar.

On an sRGB monitor, they also look essentially identical in irfanview, which isn't color managed.

Finally, on the computer with a narrow gamut monitor, I opened both in Photoshop. My working space is prophoto, so I told photoshop to keep the embedded profile for the sRGB image. I then checked to make sure that Phtoshop at had the correct, different profiles in the two images. They looked identical.

What I don't understand is why they looked so different when I switched my wide gamut monitor to a nominal sRGB gamut.

[xpatUSA]

Just now, I looked at "ProPhoto Green" suspecting that it too can not be shown by lower gamuts. I used the Lindbloom CIE calculator so as to eliminate any possibility of obfuscation by operating systems, browsers, applications, monitors, ad naus.

http://www.brucelindbloom.com/index....alculator.html

ProPhoto green is the perceived CIE color xyY = 0.159600, 0.840400, 0.711874 with a white ref of D50. Lindbloom's work is irrefutable, IMNSHO. Importantly, his calculator does not bound RGB values.

So here is that exact same xyY color properly converted to Adobe RGB (1998) white ref D65:

RGB = -99.5225, 277.4992, -82.0210

And here is that exact same xyY color properly converted to sRGB white ref D65:

RGB = -211.6837, 276.6811, -103.7462

people should realize that numbers like those can not appear in a data set bounded by 0, 255 ...

... and that, if those numbers are clipped to RGB = 0, 255, the perceived color will be incorrect on any output medium ...

... well unless any of us actually owns a Rec. 2020 monitor in which case the perceived color might be almost right.

[pschlute]

When I set my wide-gamut monitor to sRGB, the two images indeed still looked different. But when I checked on a narrow-gamut sRGB monitor, they looked identical.

My mistake, apologies. They still looked different (although less so) when I switched my wide gamut display to sRGB, and i assumed they would on any sRGB monitor. That is obviously not the case from your and Ted's experience.

[dje]

Just now, I looked at "ProPhoto Green" suspecting that it too can not be shown by lower gamuts. I used the Lindbloom CIE calculator so as to eliminate any possibility of obfuscation by operating systems, browsers, applications, monitors, ad naus.

http://www.brucelindbloom.com/index....alculator.html

ProPhoto green is the perceived CIE color XYZ = 0.135192, 0.711874, 0.000000 with a white ref of D50. Lindbloom's work is irrefutable, IMNSHO. Importantly, his calculator does not bound RGB values. XYZ is the profile connection space found in many embedded profiles.

So here is that exact same XYZ color properly converted to Adobe RGB (1998) white ref D65:

RGB = -99.5225, 277.4992, -82.0210

And here is that exact same XYZ color properly converted to sRGB white ref D65:

RGB = -211.6837, 276.6811, -103.7462

Does anyone here realize that numbers like those can not appear in a data set bounded by 0, 255?

And that, if those numbers are clipped to RGB = 0, 255, the perceived color is incorrect on any output medium ...

... well unless any of us actually owns a Rec. 2020 monitor in which case the perceived color might be almost right.

Yes Ted, an xy diagram might help clarify

Prophoto vs sRGB by Dave Ellis, on Flickr

So if the green prophoto primary has to be converted to sRGB, the CM rendering intent kicks in. I believe it treats prophoto colors within the gamut of sRGB differently to those that aren't. I'm not sure exactly what would happen to the prophoto green primary but it would probably end up close to the sRGB green primary. ie substantial clipping and color change.

It's also worth noting that the green and blue Prophoto primaries are outside the CIE spectral locus and are not considered to be visible colors, some would say they aren't colors at all!
Dave

[xpatUSA]

Yes Dave, I was just about to add that "ProPhoto Green" is invisible to humans but you beat me to it!

Fortuitously, I had also changed the XYZ values to xyY values in my earlier post.

Glad to see that someone gets it ...

[Round Tuit]

I am sorry I was not able to get back to this thread sooner.
First, I have solved my problem by installing Chrome which does manage the colours properly. I would still like to know how to fix Firefox if anybody finds out what the problem is but it is no longer imperative.

Andre,

did you try the things I tried? In particular, did you try other browsers to see if they behave the same way? And if so, did you try dragging the saved JPEGs directly into browser tabs rather than viewing on another site? In my case, the first clue is that all 4 browsers I tried behaved exactly the same (wrong) way. Then, following Peter's suggestion of dragging directly into the browser showed that the issue wasn't browsers, but the site I was viewing (Smugmug).

Dan

I did open the saved jpegs directly in Firefox without going through a web site.
P.S. Irfanview is colour managed if you configure it under "option","setting", "color management"
AND you import all the plugins.

Andre, can you post or link to the two images ?

Here they are:

#1 Adobe RGB


#2 Prophoto RGB


#3 sRGB


As for the other posts, they indicate to me that there is a lot of misconceptions about colour management and ICC profile usage. Let me try to provide a brief overview of the processes involved and hopefully correct some of these misconceptions.

An ICC profile is essentially a mapping of RGB values to real world colours which are encoded in the XYZ colour coordinates.

Lets take an RGB image tagged with a profile that we want to display on a profiled monitor with a colour managed application. The application reads the RGB values of the pixels and looks-up the corresponding XYZ coordinates in the image profile. It then uses these coordinates to get the RGB values that should be sent to the monitor from the monitor's profile. That's it!

What happens if the gamut of the monitor does not include the requested colour? The look-up function returns a value that indicates that the colour cannot be reproduced by the monitor. The application then simply substitute the colour with the closest colour that can be displayed. How we define "closest" is not simple and depends on the rendering intent. How we find this colour involves converting to the Lab space and mesuring distances in that space.

The gamut of an RGB colour space is characterized by the chromaticity of its three primary colours (red,green and blue) and that of its white point. It is worth noting that the triangle formed by joining the three primaries is NOT the gamut of the space but rather the projection of the gamut on the x,y plane in the xyY coordinate system. This means that colours inside the triangle are not necessarily in gamut but the ones outside the triangle are out of gamut. For example, the chromaticity x=0.66, y=0.33 is the chromaticity of the red primaries in the sRGB and in the Adobe RGB colour spaces. Yet Adobe RGB 255,0,0 is different than sRGB 255,0,0 and outside of the sRGB gamut.

[xpatUSA]

<>
The gamut of an RGB colour space is characterized by the chromaticity of its three primary colours (red,green and blue) and that of its white point. It is worth noting that the triangle formed by joining the three primaries is NOT the gamut of the space but rather the projection of the gamut on the x,y plane in the xyY coordinate system. This means that colours inside the triangle are not necessarily in gamut but the ones outside the triangle are out of gamut. For example, the chromaticity x=0.66, y=0.33 is the chromaticity of the red primaries in the sRGB and in the Adobe RGB colour spaces. Yet Adobe RGB 255,0,0 is different than sRGB 255,0,0 and outside of the sRGB gamut.

Agreed.

[pschlute]

Here they are:

Hi Andre.

Just viewing the three images in your post I can see three distinctly different colours for the reds. For the greens the Adobe/ProPhoto look similar but the sRGB is less vibrant.

Why your firefox is not showing you the same is very odd, and I am at a loss to explain.

[Round Tuit]

Hi Andre.

Why your firefox is not showing you the same is very odd, and I am at a loss to explain.

So am I Peter.

[pschlute]

So am I Peter.

Are you using Windows 11 by any chance ?

[xpatUSA]

Originally Posted by pschlute Hi Andre.

Why your firefox is not showing you the same is very odd, and I am at a loss to explain.

So am I Peter.

André, For what it is worth, they look the same with CiC opened in the post view.

FireFox 98.0.2, Windows 7 Pro, Dell Core i5, NEC P242W (99 pct sRGB), NEC profile set.

P.S. my monitor is connected with the analog cable (15-pin), not USB, not Wi-Fi.

[xpatUSA]

Here they are:

#1 Adobe RGB


#2 Prophoto RGB


#3 sRGB


As for the other posts, they indicate to me that there is a lot of misconceptions about colour management and ICC profile usage. Let me try to provide a brief overview of the processes involved and hopefully correct some of these misconceptions.

An ICC profile is essentially a mapping of RGB values to real world colours which are encoded in the XYZ colour coordinates.

Lets take an RGB image tagged with a profile that we want to display on a profiled monitor with a colour managed application. The application reads the RGB values of the pixels and looks-up the corresponding XYZ coordinates in the image profile. It then uses these coordinates to get the RGB values that should be sent to the monitor from the monitor's profile. That's it!

I've downloaded the ProPhoto and the sRGB JPEGs. I wanted to examine the image data values which as we know are independent of the profile unless a conversion has been done. Opened both in the GIMP. Assigned ProPhoto and sRGB then saved as TIFFs so that can view the image hex data in IrfanView. The image color data was the same in each file within one bit out 256. That tells me that there is clipping somewhere because images intended to show a given color can not have the same data if the profiles are different. It just ain't right!

Where there is clipping I have not figured out yet for sure. The embedded profiles are matrix-based with no CLUTs. Profiles with CLUTs e.g. for printing are about 250Kb - profiles with matrices are about 5Kb.

The data-to-PCS matrices are of course different between the two. For now and stating the obvious I am thinking that the difference between ours and Peter's lies in what some app or driver is doing in the pipeline going from image data via the image file profile PCS to our monitors via the monitor profile PCS.

I'd bet on the monitor driver but can't prove it today.

[Round Tuit]

Are you using Windows 11 by any chance ?

I am still using Windows 10 and do not plan on migrating any time soon.