Color Management in Raw Processing

Perhaps better still:

As an example, take any blue rectangle:
attach to it a yellow rectangle containing
the type of profile. Sort of like this:

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x                          x
x     Display              x
x                          x
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x     (Disp profile)       x
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

[Just came to think of it: I dislike the description Internal Working Image]
Image to work on?

There are also some steps which can be done on real rawdata (before a profile is assigned). For example the flatfield/darkframe stuff we have in RT

1 Like

Maybe this one from @houz

Ah, I remember it now. Looking to see if I’m just rehashing good work…

1 Like

@houz: If you haven’t already seen my endeavor, I’d greatly appreciate your take on it…

I like the color profile icon…

It’s a good soup-to-nuts depiction, includes specifics I hadn’t contemplated. Doesn’t address the camera profile and it’s role with the original image. To my thinking, color information is metadata that is as important as the image width and height, and it has a “chain of custody” that starts with the camera profile assignment to the initial raw array.

Revision 2. The contemplated title: “Color-Managed Raw Processing”, focuses it on a specific use case. This’ll be my last revision today, but I’ll keep reading feedback into the evening…

4 Likes

which software did you use for this mind map?

This seems correct to me, the only thing I might add in some way is that effectively the RAW file is already in camera color space, it is just that the software/computer doesn’t know what this is, effectively the assign is to tell the SW that something is in a certain color space. On the other hand I have no idea how to clearly communicate that without confusing people even more so maybe it is better to leave it as a technical detail.

(also like @betazoid I would like to know what you used to create this mindmap)

Despite a lack of technical knowledge in that matter, I’ve quickly understood the difference between “assign” and “convert” with regards to profiles. To me, assigning is simply tagging. For example you can assign the “orange” profile to an “apple”, people reading the tag will say “hey, look at this orange”, but it still is really an apple. Converting would be really changing the apple into a real orange, and that’s why converting an image into another profile requires some wizardry.

Regarding @ggbutcher’s workflow, I view the “Working image” not really as an image, but as data. The software doesn’t care about data being an image, or a sound file. At this point it is not really an image. The image is what is displayed. Just my 2 cts.

1 Like

@betazoid & @dutch_wolf , FYI: Freeplane is a truly (IMnot-soHO) spectacular mind mapping program which I probably use far too often. Nevertheless, I think that Glenn’s very helpful graphic is more of a Flow Chart rather than a mind map.

I’m not sure which program he’s used but, I often use Dia, when having to create diagrams of Industrial Process Flows. It likewise produces Flow Charts similar to Glenn’s.

1 Like

Morning!

Here is a rough sketch of what I mean:
aaa

Also: I feel that gamut might need an explanation.

PowerPoint. It was the only hammer in the toolbox in front of me when the notion came to mind…

Im starting to think about the prose that would go with it, and that is the essential point of ‘assign’’

1 Like

I’m going to be tied to in day job for a few days, but I’ll still be considering and incorporating all your comments. Thanks!!!

2 Likes

With regards to “assign” and “convert”, would the following analogy help? If you record raw video at 25 frames per second, you can assign any framerate to the frames. This will simply interpret the data without effectively changing it, speeding up or slowing down the video with respect to reality. However, if you convert it to another framerate, for example 30 frames per second, the effective speed of the video will stay the same, but you will need to create 5 additional frames to fill up the missing data points.

Does that make any sense if you apply this to color management?

@Thanatomanic, I think it does, in the following context: image data has certain fundamental characteristics, knowledge of which are critical to its interpretation. For instance, a program can’t make fundamental sense of a glob of memory storing an image without the numbers width and height: without that, it’s just a long list of bytes. bit-depth and number of channels are also important in that same way.

To my thinking, same thing applies to color primaries and white point. Whether anyone likes it or not, every digital image being passed around or processed or captured or displayed corresponds to a specific color space, anchored by a white point. That starts with the camera profile, assigned to the camera image by whatever processor is going to make it pretty, and stays with the data array until a specific conversion takes place to some other color space. Then, the data corresponds to a new color space, and those primaries and white point need to follow the data around to the next conversion.

There are some metadata conventions that try to shortcut that information passing, such as DCF tags. If you find an EXIF::ColorSpace tag in a file, it’ll say something like ‘sRGB’. Well and good, no? Probably not, as there are a lot of notions floating around about what specifically is sRGB. @elle has a good article on all that:

https://ninedegreesbelow.com/photography/embedded-color-space-information.html

To my skeptical thinking, at least the 3x3 matrix of color primaries, and the triple that specifies the white point, are the fundamental definitive specification of color space. And that metadata needs to follow the image, from creation to depiction.

Hello,

the difference between “assign” and “convert” is nicely explained on Elle’s website.

If you assign a profile to a file, the pixel values are not changed. The file is only tagged how the pixel values have to be interpreted in terms of device independent values (XYZ or Lab). If you change the assigned profile, the Lab values displayed e.g. by RT will change accordingly.

If the profile is converted, the pixel values are changed according to the prescription of the profile. If you measure the Lab-pixel values they will stay constant, regardless to whatever profile you converted to. You only changed the colour space, not the colour values (Lab).

This is how I understand Elle’s description. :slight_smile:

Hermann-Josef

1 Like

No, too complicated!
What prior knowledge do you expect the reader to have?

@Claes, these are the essential words to convey the mechanics.

I think, if the colorspace information is considered metadata, the only appropriate use for ‘assign’ is at the very beginning, to associate the raw array with its color space. All the other color management operations are ‘convert’. Same thing with width and height; the first connection of those attributes at capture is ‘assign’; later, if cropped, the image gets a new corresponding width-height pair…

Perhaps… but if assign does not change any pixel values,
why on earth bother!?