@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…
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.
@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.
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:
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.
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).
@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…