The good news is: they are all “well behaved”.
But RawTherapee’s profiles are “my” favorites, because they have TRCs (tone response curves) with 4096 points instead of 1024 by all others.
I created a spreadsheet for better overview. If you want, you can download it here: CP-Evaluation.zip (61,6 KB)
Inside the ZIP you’ll find the same spreadsheet with
.ods extension for LibreOffice,
.xlsx for Excel 2007-365 and
.xls for Excel 97-2003.
Scroll to the right for overview, the first column is fixed.
I renamed the “Large” profiles (by Elle and RT) back to “ProPhoto”, for better overview.
Unfortunately xicclu.exe issn’t compatible with V4-profiles and ICC Profile Inspector only shows basic informations of V4-profiles. So some lines of the V4-profiles are empty…
Maybe someone is interested in that stuff and maybe it will be useful for someone other.
Hmm, that was interesting to read! So I’m a little bit in trouble now, of what or whom to believe
Photosauce is telling me, that a 1024 points curve is more accurate than a 4096 points one.
And RawPedia told me before:
-Output Profile-
…
“RT_sRGB is a higher quality version of the standard sRGB profile, which surprisingly is inconsistent between implementations. RT_sRGB was custom-made for RawTherapee by Jacques Desmis and has 4096 LUT points, as opposed to the lower quality 1024 point sRGB profiles. Applications that aren’t color managed and won’t take advantage of RT_sRGB will fall back on sRGB.”
-Working Profile-
…
“Note that the working profile will only specify the red, green and blue primaries, gamma will not change as RawTherapee’s processing pipeline is floating point with no gamma encoding (that is gamma = 1.0). Some tools (like curves and histograms) will still display with a gamma (usually sRGB gamma) which is hard-coded for the tool and stays the same regardless of working profile.”
Furthermore you can adjust TRC manually by “Tone Response Curve: Custom”
For Output Profiles I understand the demand for “space saving” tiny profiles as they will be embedded to each JPG. But in my personal opinion I think that it doesn’t matter to save a few KBs with each photo on todays TB-drives. And as I don’t know under which enviroment my photos will be displayed outside my system, I don’t mind about (mostly) invisible color or tone deviations. I’m not responsible for other people’s equipment
So, what is wrong or right, black or white?
Btw, another interesting topic about working profile TRC:
For example, the value for an input of 2/255 should be 0.0006070540. Quantized to 16 bits, that value becomes 40/65535, which is actually 0.0006103609.
@heckflosse Have you read that photosauce-article too?
What I don’t understand is this:
“…You can see that the max error has actually gotten worse with the bigger curves. The reason for this is that with more points defined in the curve, their values get closer together, and the quantization/rounding error becomes more significant. If we look at the linear segment of the 1024-point curve, we can see the issue.
0,5,10,15,20,25,30,35,40,45,50,55,59,64,69,74,79,84,89,94,99,104,109,114,119,124,129,134,139,144,149,154,159,164,169, 174,178 ,183,188,193
Notice that there’s a nice even increment of 5 between each step… except for two times where it’s 4. That uneven step hints at the fact that the slope of the line allowed by the quantization to 16 bits is not quite right. The only way to make it better is to remove points so that the slope can be represented correctly…”
Yes, but only up to the point I quoted. That (showing a conclusion before showing the cause) let me to ignore the remaing part of the article. I will read again now.
I just decided not to read the whole artilce because:
If someone writes an article which includes math and the math is not correct at the beginning, all conclusions may be wrong, means searching for the truth is a waste of time for others. Writer of the article should fix the math, then we may have a look again
Nice statement
My logic was like: more information = better results.
Cannot imagine: less information = better results.
So we’ll see…
I keep going with RT’s profiles anyway
I guess I’m developing a more simplistic perspective on this. LUTs have their place in capturing transfer functions that can’t be expressed mathematically, but if the destination for display or printing is 8 or even 10 bits, do these discontinuities really matter?
To be honest. I know nothing about RT’s profiles. I rely on others for this part of RT. About the article it was just about reading up to a point where I found a possible error in the calculations and then stopped reading…
@ggbutcher
That was what I ment by saying: “…And as I don’t know under which enviroment my photos will be displayed outside my system, I don’t mind about (mostly) invisible color or tone deviations. I’m not responsible for other people’s equipment…” So I think it doesn’t matter in private sector, but maybe a little bit in commercial sector and for sure in scientific sector.
@heckflosse
Okay, but maybe you know someone who cares about RT’s profiles (and would be interested to clear-up something wrong here, or even at photosauce…)?!
Hi afre.
I’ve searched the forum for output profile stuff - but found nothing really similar.
And what do you mean with “…but perhaps not to your satisfaction.”?
Sorry for being vague; I have been busy and don’t know enough to offer definitive remarks. All I can say is that there are posts that talk about points and precision of profiles. People have different opinions on their quantity, quality and acceptability, which is probably part of the reason that some profiles don’t work with certain apps.
Profile choice and colour space design also depends on your workflow, from conception to end product. In this, there is no one true way, though one might say there are better choices.
For sure. But the most it depends on output (format and purpose - print, presentation, webview…)
I believe this (and color management in general) is a barrel without ground. There will always be discussion and disagreement about this topic. And I know that there never will be a unified or universal solution which fits for everybody and every purpose…
My (personally) logic is this:
While working with RawTherapee I also use RawTherapee’s different profiles. I trust their developers and (imho) this combination should work very well together. If not, somebody should prove the opposite to me. End of story.
But where I have problems with trust is when individual people lecture over pages and pages about a “problem”, trying to prove something abstract while working with incorrect math and dubious sources. As I found in an old article here:
The only exception for me here is Elle Stone and Graeme W. Gill. Because their math and logic is correct and proved by many experts. Even I can retrace and confirm Elle’s theories and results.
As photography in general and digital photography in particular bases on pure math, there should always be a right OR wrong, true OR false and nothing (distorted) in between.
Of course there are many ways to go. But one certain way to one certain purpose should be true, from the beginning to the end.
Btw. The most that I’ve learned about RAW and it’s processing was written by Iliah Borg and Alex Tutubalin (Developers of LibRaw, RawDigger and FastRawViewer). If you would like to dig deeper in math and scientifical side of digital photography, you will find a bunch of articles by them scattered over the web…
Ahh, okay.
Sorry, but english is not my native language. So I’m sometimes in trouble with some phrases
Thanks, I think that I’m on a good way. Waiting for answers of an expert who’s at vacation until end of the month… Then we’ll see.
Regards
In short:
Jacques Desmis, Graeme W. Gill and Elle Stone are right. Photosauce is wrong, when passing from linear to parabolic. A lower number of TRC-points leads to more «fish bones» in the histogram. That was already 10 years ago the “problem” and it will be the same in another 10 years. Because it’s true math.
End of Story
But this article will may be useful for someone else, who’s also stumbling over these stones in the future