Is it possible to make the arrow span the length of XYZ? It is too short for my tastes. 
If I knew how I would
@dutch_wolf there you go
\overrightarrow{XYZ}_R * R+ \overrightarrow{XYZ}_G * G + \overrightarrow{XYZ}_B * B = \overrightarrow{XYZ}
2 Likes
Sorry if this is off topic, I’m just learning about this things and this is really helping.
In darktable the input color profile module provides several options for the profile (standard color matrix, custom icc, etc) and uses an in memory Lab profile to do the actual transform. Is that Lab profile the working profile you refer to? (even if is not RGB)
No, your working profile should be something like ProPhoto or some other wide gamut profile, or Rec 702 or Rec 2020 if you want a linear profile.
I’m going to leave it to one of the darktable folks to give the definitive answer.
If I had to guess, there’s probably a separate conversion from whatever RGB space is the working profile to LAB, so that tone manipulation can be done without dorking up the color. If an image is in LAB colorspace, if you apply a curve to the L channel, you’re modifying Luminosity, independent of the other two channels, which describe the color. There’s differing opinion on whether this is a good idea.
It can be a bit confusing because LAB is also one of the intermediate colorspaces that can be used to do transforms, at least per the ICC spec. So profiles don’t need to know about each other, transforms are done through an intermediate color space called the Profile Connection Space, or PCS (never too many acronyms…) So, when the software transforms your image from the input camera profile to whatever working profile, it’s actually done inputprofile → PCS → outputprofile. XYZ and LAB are the two spaces the ICC calls out for use as PCSs; XYZ is the most-often-used one, in my limited experience.
Darktable doesn’t really have a RGB working profile it does (almost) everything in LAB so LAB is the working color space for darktable. At the time this seemed like a good idea due to LAB covering the full human visible gamut (so anything the camera can see will be covered) and the inherit separation of chroma from luma, alas you run into issue since LAB is perceptual uniform which isn’t the greatest way to edit[1]. The other issue is that LAB is ‘here be dragons’ territory with regards to editing HDR[2].
TL;DR for now the working ‘profile’ of darktable is LAB (some people are working to change this but it is a slow process since they want to preserve older edits)
[1] For historic reasons a lot of editing was done perceptual uniform since it could be done with only 8 bits per channel but now that we can do 32bit float editing in a linear space gives a lot less artifacts
[2] There has been done some research but what I could find is that although L* is surprising accurate to well above 100 is is unknown how accurate a* and b* are at those L* values.
1 Like
I used darktable as example because I’m familiar with it and (some of) the code, but my goal was to understand what the working profile is, and is more clear now, thanks.
Is there a PR for that? Maybe I’m duplicating efforts…
I don’t think there is a pull request but I think I heard @anon41087856 talk about working on it
1 Like
Imho, raw processing is mainly in RGB space. The input (raw files) mostly is in rgb space (with some very rare exceptions) and the demosaic is also done in RGB space (with some exceptions, as in xtrans Markesteijn and bayer AHD demosaic, where an intermediate conversion to Lab or YPbPr is done).
After demosaic the image is not raw anymore, means the conversions after demosaic don’t fit to the topic of this thread.
It may help to remember that RGB profiles are essentially three components:
-
Chromaticity of the white point, expressed as either x and y, or X and Y and Z. (In theory, chromaticity might be expressed as a* and b* of L* a* b*, but it isn’t usually.)
-
Likewise chromaticity of the three primaries.
-
Transfer function, aka transfer curve or tone response curve (TRC). This might be a simple power (aka gamma) curve (eg AdobeRGB1998), or a linear portion plus a power curve (sRGB, Rec709, Rec2020, ProPhoto). This doesn’t affect chromaticity.
(1) and (2) can be combined with a 3x3 chromatic adaptation transfer (CAT) matrix to make either a 3x3 chromatic adaptation matrix (CAM), or a look-up table (LUT).
Common CATs include Bradford, CMCCAT2000 and CAT02.
Or all three components could be combined with a CAT to make a single LUT. I don’t think this is normally done.
From any profile that has been correctly specified, we can easily reverse-calculate to find the chromaticities of the WP and primaries.
Assigning a profile merely attaches this metadata to the image (aka embedded profile).
Converting to a profile also recalculates image pixels. Converting an image is always from one profile to another profile. If it has no attached profile, it can’t be converted. However, when there is no attached profile, software may assume some version of sRGB.
We also need to know that there are many versions of sRGB or Rec2020 etc profiles, partly because there are many versions of “standard” illuminants D50, D65 etc, partly because the best guesses for physical “constants” changes with the years, and partly because different levels of precision are used.
Analogies may be helpful, but I suspect they often add confusion. A raster image in a computer is essentially a large quantity of numbers for the pixels, and associated metadata that specify what colours should be produced from the numbers. Data and metadata.
1 Like
At work, after having to undo misunderstanding based on a couple of bad analogies, I’m much less a fan of them.
Yes, I have read some of those papers. I recall there being proposals for an HDR-CIELAB. I wonder though at what point do we move on to other models such as CIECAM02 or CIECAM16, etc.
I’m still cogitating a post of some sort that incorporates the cartoon all of you have helped with, but I’m sidetracked right now doing work with the nascent librtprocess library. I’m thinking of a few more cartoons, ones that describe things like the transform operation (inputprofile → PCS → outputprofile), and the like, surrounded by a post of prose…
1 Like
I always thought of CIECAM as less of a color model and more of perception model useful for adjusting for certain difference in for example surrounding, but are not really intended as spaces to edit pictures in.
More cartoons please! Vert useful - really! - and collect great feedback almost immeditely.
Apologies, my attention diverted to … SQUIRREL!!!
…
Sorry, back again. Okay, here’s R3:
I made a profile icon from a ppmcie graphic. Note that the Maxwell gamut triangle gets smaller as the workflow progresses, in the manner a camera → working -output color migration would happen in practice. Not sure what to say about that on the chart; in my mind, that’d be described in the accompanying prose.
I do intend to make something of this, but my attention span will be a bit fragmented in the next couple of months
3 Likes
Pretty pictures always helps with the experience. 