Matrix multiplication

Processing
21

“White point” might mean the white point of the ambient light in the room, or the white point of the display, or the white point of the sRGB color space spec, or the illuminant of the sRGB color space profile, which for V2 and V4 ICC profiles as @ggbutcher notes the illuminant is always fixed at D50.

Here are some silly examples that might help to clear up some potential areas of confusion, or maybe not :slight_smile: . Keep in mind that V2 and V4 ICC specs assume that your eyes are 100% adapted to the “color of white” of the display:

Imagine a display calibrated to exactly match the sRGB color space specs. It would have a D65 white point, same primaries as sRGB, and same TRC as sRGB.

Imagine that you send the image to the screen using GIMP or other software that can use ICC profile color management, but you disable color management. The colors would be correctly displayed.

Imagine that you told your imaging software to enable ICC profile color management, and that you assign the sRGB ICC profile as the monitor profile and also as the image profile. The image would look exactly as it did before you enabled color management, even though now you are using ICC profile color management.

Now imagine that your monitor is actually calibrated to match AdobeRGB which also has a D65 white point but is a larger color space than sRGB, and you continue using the sRGB ICC profile as the monitor profile and also as the image profile (or else you simply disable color management, same result either way). The image will not look right. The colors will be too saturated, but neutral gray and white will still look right, no yellow or blue color cast.

Now imagine that your monitor is actually calibrated to exactly match the old ColorMatch color space with its D50 white point and primaries sort of close to sRGB primaries, and you continue to use the sRGB ICC profile as the monitor profile and also the image profile - the colors will be somewhat close to correct, but there will be an overall cast - white and grey will actually look yellow.

1 Like
22

@Elle

Another example. This time using additions and not overflowing the max float value:

    float f1 = 1e-1f;
    float f2 = 1e9f;

    float f3 = 0.0f;
    
    // sum up small values first
    for(int i = 0; i < 100000; ++i)
        f3 = f3 + f1;
    
    // then add large value
    f3 = f3 + f2;
    std::cout << "result 1 : " << f3 << std::endl;


    f3 = 0.0f;
    // add large value first
    f3 = f3 + f2;
    // then add the small values
    for(int i = 0; i < 100000; ++i)
        f3 = f3 + f1;

    std::cout << "result 2 : " << f3 << std::endl;

result 1 : 1.00001e+009  <= correct
result 2 : 1e+009        <= wrong

I agree that in this discussion it shouldn’t play a big role. I just mentioned it because a lot of people are not aware of that.

1 Like
23

In most V2 or V4 ICC profile color managed applications, if the image file doesn’t have an embedded ICC profile the application assigns the sRGB ICC profile with its D50 illuminant. I know of two applications that tried to do something else, but their users complained.

Could you give a link to which spec suggests D50 as the viewing environment, and a quote of the relevant passage?

24

Yes as example that is how I think RT works.

https://www.w3.org/Graphics/Color/sRGB.html
check the section on sRGB reference viewing environment, it is quite confusing…

25

Hmm, yes, I thought maybe that might be what you were referring to. The thing is, sRGB as described in the original specs was never was meant to be a monitor profile or even an editing color space. It was meant to be used when displaying images on Rec.709 monitors - not using any kind of color management other than hopefully a properly calibrated monitor - under specific viewing conditions, meaning the brightness and color of the ambient light in the room where people are looking at stuff displayed on the monitor. Plus there is consideration of flare off the monitor which raises the effective black point of a CRT, which theoretically was zero (the CRT guns could be off), but in practice never was.

In other words, sRGB specs are trying to deal with the inescapable fact that the viewing conditions around the monitor influence how colors are perceived on the monitor, in addition to considerations of how the monitor itself should be calibrated. And sRGB specs also deal with “actual” vs theoretical black point of displays, but specifically of the old CRT displays.

In yet other words, sRGB specs are trying to deal with what we refer to more broadly as color appearance considerations, plus some considerations that were specifically an aspect of looking at a CRT in a dim viewing environment.

All this stuff is important, but the specific numbers and such in the spec only apply to actually looking at a monitor calibrated to Rec.709 under specified viewing conditions and not using ICC profile color management. How many people looking at this thread fit this description?

In a practical sense, the only part of the original sRGB specs that we incorporate in V2 and V4 ICC profile color-managed editing applications is the primaries and the white point, which we then immediately adapt to D50 to make the sRGB ICC profile.

We really should also pay attention to other things mentioned in the original sRGB specs, like “how bright is the room” vs “how bright is the monitor” and “what color of white for display” vs “what color of light for the surrounding ambient light” and “how dark is the darkest displayable dark” and etc.

But the specifics of how to manage these ambient light levels and “colors of lights” will depend on one’s very specific editing goals. An ICC profile color-managed print-oriented workflow on modern LCD monitors probably wouldn’t involve using any specific numbers from the original sRGB specs even if the person actually intends only to print sRGB images.

26

Perhaps the other reason, is that many people myself included probably expect a color managed file with the correct sRGB profile applied to look the same a plain file with assumed sRGB values to look identical?

27

Hi,

I haven’t checked the link, so I’m not exactly sure of what you are trying to
do, but here’s my understanding of your problem (if I got it wrong, sorry).

You have a column vector rgb (i.e. a “colour”) that you want to convert to another one RGB in a different space. You can do that by “applying” two matrices M1 and M2, and you would like to see whether you can do it by just using one matrix M. Did I get it right?

Then, you have this:

xyz = M1 . rgb

RGB = M2 . xyz

substituting for xyz in the 2nd equation:

RGB = M2 . (M1 . rgb)

Knowing that matrix multiplication is associative (forgetting about what @heckflosse wrote about floating-point operations, it is definitely true but I think it can be left out of the conversation here), you get:

RGB = (M2 . M1) . rgb

Therefore, M = M2 . M1, i.e. you would multiply “in reverse”. Does that make sense?

2 Likes
28

Could you give an explicit example of the problem you are talking about, perhaps with screenshots? You mentioned RawTherapee a couple of different times - is there something RawTherapee is doing with sRGB images with and without embedded sRGB profiles, that somehow seems unexpected?

29

Spot on!

Yes that is very helpful! and is exactly in agreement with several examples I have.

30

I am using the RT code as reference, for what I am trying to do. Ideally I would like to incorporate my work into at RT some point!

Specifically I am trying to create a matrix that will take color values that I have computed from density readings of a film scan, that should be in a particular colorspace. Lets call that colorspace RA4 space. (i.e. the colorspace that is created by using the CMY dyes in a RA4 processed color print)

I then want to transform that data to sRGB correctly. At least that is what I want to do initially…

That’s why I want understand how to do it properly! Once I have got the method correct I may do things slightly differently. But my goal initially is to do it correctly.

I can make up some examples using generated solid colors, and compare the results that I get from RT.

31

I’m totally confused as to how your inquiries regarding viewing conditions is related to "Perhaps the other reason . . . " as quoted above.

There are many web browsers that fail this test of “sRGB image looks the same with and without an embedded sRGB ICC profile” - are you talking about something you see in a web browser?

32

Perhaps a step back is order.

What I am trying to should be straight forward in that I want use the exact same methods that are used in digital photography and some extent even more so those used in RT. (which I hope are same etc…) The only difference is my values “camera” to XYZ are unique.

This involves a lot of trial and error, trying different things, and each time I try something I like to understand the process, the values used etc.

I understand this because the software simply ignores the values. But in the case of software that processes ICC profiles correctly what should happen?

Perhaps I can ask the question in different way. Let take two tiff files. File A has the correct sRGB value attached with D50. and File B which has the exact same data inside but no profile.

When the same file is displayed in RT should they appear the same or different? Or what color values does the internals or RT thinks it has?

33

Hmm, I thought I already answered this question above :slight_smile: . The files should look the same assuming the software assigns sRGB to images without embedded ICC profiles, which I’m sure RT does, leastways I can’t see any change in how a sample image looks before and after assigning an sRGB profile to an image with no embedded ICC profile. Do you see a visual difference?

I’m not sure what you mean by “ignores” but the problem is that those web browsers are flawed :slight_smile: . They should all by default assign sRGB to images without embedded ICC profiles, and then convert to the monitor profile.

34

No, hence my point that when no profile is applied RT assumes it sRGB at D50, and I assume so does many other applications. If it assumed the file without the profile was D65 it should apply an adjustment and the result should look different to the one with D50 profile?

Putting aside applications that don’t do things correctly I am looking to understand what the correct behaviour should be. Does that make my question clear?

35

If a V2 or V4 ICC profile color-managed editing application assumed an image without an embedded ICC profile was somehow “D65” and then tried to apply an adjustment to somehow compensate for the difference between D65 and D50, it would be a very confused ICC profile color-managed editing application.

If I were using software that behaved in this fashion, I’d file a bug report.

36

Very sorry @LaurenceLumi, the confusion was all mine. @agriggio explains it perfectly. Of course it’s not A * B * C because the input pixel is a vector, not a 3x3 matrix therefore needs to be on the rhs of each multiply! Incidentally, gmic has the mix_channels command for that. I think I’ll keep quiet now :slight_smile:

1 Like
37

I can’t help but think that I’m somehow missing the question that you are actually asking. An sRGB ICC profile already has the “D65” source white point incorporated into the profile by means of the chromatic adaptation that was used to make the sRGB ICC profile from the sRGB color space specs. It doesn’t have to be added again, in the context of using ICC profile color management.

I tried an experiment once, modifying LCMS to use D65 as the illuminant, instead of D50. I installed the modified LCMS in /usr (this is on Linux) so all ICC profile applications used this modified LCMS. And I made a set of ICC profiles that used D65 as the illuminant. With this modified LCMS, when making ICC profiles from color space specs, D65 color spaces didn’t need to be chromatically adapted to D50. But D50 color spaces such as ProPhotoRGB did need to be chromatically adapted to D65. And of course “E”, D60, and etc color spaces still needed to be chromatically adapted, but to D65 instead of D50.

When I tried editing using this modified LCMS and the modified profiles with my editing software such as GIMP, all the colors looked exactly the same. Exactly the same. The only way I could get “different colors” was to:

  • Use my “D50 illuminant” ICC profiles with my modified-to-use-D65 version of LCMS
  • Or else use my “D65” version of LCMS with my normal D50-adapted ICC profiles: Edit: What I meant to say, should have said, was “Use the D65-illuminant profiles with normal non-modified D50-illuminant LCMS”.

Sometimes you might run across an incorrectly-made sRGB ICC profile where the chromatic adaptation from D65 to D50 wasn’t done. Using such a profile makes images look blue, such as the image below on the right (the colors on the left are correct):

Back in the days of V2 workflows, you could “get different colors” - either blue or yellow or even other colors depending on your monitor’s actual white point, by using Absolute colorimetric rendering intent to the monitor.

You could also get different colors when converting from one ICC RGB working space to another ICC RGB working space with a different white point, but you had to specifically ask for Absolute colorimetric intent - all the editing software I’ve ever seen defaults to Perceptual or Relative, so nobody was likely to do this accidentally.

For example, you might convert from from sRGB to BetaRGB (which has a D50 white point) or vice versa, using Absolute colorimetric intent, resulting in images such as are shown below. Notice the image on the right is “too yellow” and the image on the left is “too blue”:

But the ICC decided this sort of color change when using Absolute colorimetric was confusing to users.

So for V4 workflows, when the source and destination color spaces are both “monitor class” profiles (all the standard RGB working spaces we use in the digital darkroom are “monitor class” profiles), when you ask for Absolute colorimetric rendering intent, what you get is Relative. Which makes it decidedly more difficult to write tutorials that encourage users to experiment and thus learn for themselves first-hand the difference between relative and absolute colorimetric intents :frowning:

The images above come from my article on “Will the real sRGB profile please stand up”, which was written when I actually had access to V2 editing software: https://ninedegreesbelow.com/photography/srgb-profile-comparison.html

1 Like
38

Specifically if I am creating data to store in a file that does not have ICC profile attached what parameters should I use?, and what parameters should I use if use a ICC profile with the correct primaries, and D50 white point etc ? Initially I though I should use the sRGB primaries and D65 for the former and D50 for the later.

But that does not seem to fit what the software I am using as example does. It seems rightly or wrongly that if you want the software to work as expected you need to create data in the former (the file without the ICC profile) with a D50 white point. As the software will NOT make any chromatic adaptation.

39

Hmm, well, the only answer anyone will ever be able to give you is that for V2 and V4 ICC profile applications, use the D50 adapted matrix for sRGB. Whether the profile is actually embedded in the image or not is irrelevant. I’ve tried to give reasons why several times in this thread, but as I said, I’m not hitting the area that answers your questions, and at this point I somewhat doubt my ability to do so :slight_smile: .

If you don’t want to use a D50-adapted matrix, wait until someone adds iccMAX support to an ICC profile color managed editing application, in which scenario I don’t have much of a clue what will happen or be possible. But don’t try to mix whatever you do using iccMAX applications with what you do using V2/V4 applications.

Or else don’t use ICC profile color management at all, and instead use OCIO color management, which requires using OCIO LUTS to get from whatever color space the image is in, to whatever color space you want the image to be in. But I’m not the person to advise you on the specifics of OCIO, if that’s the direction you want to go. If you do a search on the forum, there are already some threads on the topic.

Here is a thought: Go ahead and try whatever it is that you think should be done, as you generate the matrices for whatever application you have in mind. And if it works, great! Experimenting with doing whatever you think should work is a great way to learn what does work. In general trying stuff and seeing what happens, and then figuring out why really is a nice way to learn stuff.

40

Bear-of-little-brain here, methinks that 1) if you’re going to put primaries and whitepoint information in an image file, it should represent the color gamut to which the data was last converted, and 2) if you’re not going to put that information, you need to ensure the color gamut of the data can be used as-is by whatever media the data is intended for.

You can combine #1 and #2 for the largely unmanaged wild of the web by converting and storing sRGB/D50 (D50 mainly because the ICC tells people that’s their notion of reference whitepoint) and pray someone’s not going to regard your image on a cheap projector, ask me how I know…

I think the primary consideration is to ensure the metadata properly represents the image characteristics, and in its absence you need to have particular media in mind.