How to get the best raw exposure, part 2

Could we not delete the whole 625 comment/argument/grandstanding thread about Exposure Triangles and replace it with just this post?

It's also pretty much what I posted in my op in my The Exposure Triangle Is Misleading And Unnecessary thread.

That weird slope between 800 and 1600 is there because Canon uses digital amplification between power-of-two ISO values, e.g. 1000 and 1250 will be 'digital', and 800 and 1600 - 'analog' - the reason I use full stop steps for ISO. The R5 isn't 100% ISO-invariant but good enough.

Perfectly good sense, thank you.

Apologies for accidentally slipping the word exposure in there, it's so difficult to avoid using a natural and convenient word and disrespecting its technical usage. I find that when I type out something, it takes me typically 5 revisions to correct all the typos, get the sentences in the right order, add in the words I accidentally missed out or duplicated or fix where I simply chose the wrong word. In professional communications we tend to try much harder, but for forums it's often rushed or casual. This forum has a preview function which is good, but I still find myself doing my DPReview habit of posting then reviewing, editing and correcting repeatedly. My bad, will try to do better!

ps

When you submit posts like this, I consider them a public service and thank you. It's the unending arm wrestling with certain posters that gets tedious.

pps

On the subject of good communication... I attended the Fully Charged Live EV trade show at Farnborough airport a couple of weeks ago. During the visit, I sat in the Vauxhall Astra EV and admired their wrap around dash design. A rep got me to sign up for info. Today I had 3 phone calls and two emails from two local Vauxhall car dealerships. I didn't take the calls because I didn't recognise the number, but one email thanked me for signing up and booking a sales call with the dealership (I did not), the other thanked me for my interest in the Astra but declared that sadly, there was no EV model. I emailed back and told them I'd sat in the car two weeks ago. They emailed back and said they had checked and there was no EV. Then 3 minutes later, they sent another, chastened email, apologising, After double checking there was indeed a new Astra EV, but they knew nothing about it.

Communications matter, and mood and emotion normally matter a great deal more than correct grammar and word choice. I wonder how WJ King of Dartford feel my emotions about Vauxhall, the car company, were affected by this little piece of farce?

100% agreed

Difficult to say this without sounding rude, so I apologise in advance, but that sounds like ridiculous pedantry to me. ETTR is a technique for acquiring a good exposure. We both agree (I think), that if our goal is to achieve the lowest noise and widest DR when shooting raw at base ISO, we have to get as much light on the sensor as we can without clipping key highlights. ETTR is a convenient term to use when discussing this.

The practical way I do that is by twiddling the exp comp dial until the preview histogram indicates it has reached the clipping point. Then I take the picture. Then I check the post capture 4 channel histogram just to confirm none of the channels is shown as clipped. That's it for me.

That action is what I think of in my head as "acquiring the best exposure I can". I never discuss this process with anyone outside forums, so I don't need a name for it in real life, it's only on forums I call it by the convenient term ETTR (because that term was popularised by Michael Reichmann and has been adopted with enthusiasm by lots of others). It's just a name! It may be a process rather than a thing but in a discussion, the end goal is implicit. It doesn't need to be spelled out in full. When someone asked me "what do you call a good exposure" and I answer "ETTR", it is surely perfectly obvious to anyone that I'm using "ETTR" as a convenient shorthand for "I use ETTR techniques to maximise the exposure to just before the clipping point for highlights". What other single word term is there? By all means differentiate the concepts in your head if that helps, but be reasonable when it comes to chatting on a forum. It seems we have been arguing about nothing practical at all, all along, just the neat categories you like to maintain in your mind. I can only think you read too much Wittgenstein....

ps

I accept it's only a jpeg histogram and I'm probably leaving half a stop of noise reduction on the table, but they don't provide the right tools in cameras.

pps

"Hoover" - a brand name of a manufacturer of vacuum cleaners. "To hoover" the act of using a vacuum cleaner. It's how language evolves and works...

116K green pixels clipped?

Floating point.

I cannot guess how one might apply a gamma curve without floating point or at least fixed point arithmetic or scaled integers. For modern CPU hardware use of floating point arithmetic and standard library functions is much faster. Quantization error will also occur at the analog to digital step if it is anything like the A2D converters that I worked with many decades ago. Quantization error will always occur when converting floating point to integer, but as you wrote it may be insignificant and I might no longer be able to do the analysis. The greatest quantization error would most likely occur in the portions of the curve where there is the most stretching of the linear data.

It appears to me that libraw outputs a 16 bit integer TIFF. (GMIC will output a floating point TIFF by default and must be told to use a unit16, so far as I can remember).

The source code below from libraw does an implicit type conversion on assignment from double precision floating point to an integer that can be represented as 16 bit unsigned. (an unsigned short is at least 16 bits so far as I can remember). It appears to me that a lookup table is created which is later used by:
if (use_gamma)
{
unsigned short curve[0x10000];
gamma_curve(curve);
for (int j = 0; j < S.raw_height * S.raw_width; j++)
RawProcessor.imgdata.rawdata.raw_image[j] =
curve[RawProcessor.imgdata.rawdata.raw_image[j]];
if (verbose)
printf("Gamma-corrected....\n");
}

/home/jrm/src/libraw2021dec18/LibRaw-master/src/utils/curves.cpp lines 81-151/151
void LibRaw::gamma_curve(double pwr, double ts, int mode, int imax)
{
int i;
double g[6], bnd[2] = {0, 0}, r;

g[0] = pwr;
g[1] = ts;
g[2] = g[3] = g[4] = 0;
bnd[g[1] >= 1] = 1;
if (g[1] && (g[1] - 1) * (g[0] - 1) <= 0)
{
for (i = 0; i < 48; i++)
{
g[2] = (bnd[0] + bnd[1]) / 2;
if (g[0])
bnd[(pow(g[2] / g[1], -g[0]) - 1) / g[0] - 1 / g[2] > -1] = g[2];
else
bnd[g[2] / exp(1 - 1 / g[2]) < g[1]] = g[2];
}
g[3] = g[2] / g[1];
if (g[0])
g[4] = g[2] * (1 / g[0] - 1);
}
if (g[0])
g[5] = 1 / (g[1] * SQR(g[3]) / 2 - g[4] * (1 - g[3]) +
(1 - pow(g[3], 1 + g[0])) * (1 + g[4]) / (1 + g[0])) -
1;
else
g[5] = 1 / (g[1] * SQR(g[3]) / 2 + 1 - g[2] - g[3] -
g[2] * g[3] * (log(g[3]) - 1)) -
1;
if (!mode--)
{
memcpy(gamm, g, sizeof gamm);
return;
}
for (i = 0; i < 0x10000; i++)
{
curve[i] = 0xffff;
if ((r = (double)i / imax) < 1)
curve[i] =
0x10000 * (mode ? (r < g[3] ? r * g[1]
: (g[0] ? pow(r, g[0]) * (1 + g[4]) - g[4]
: log(r) * g[2] + 1))
: (r < g[2] ? r / g[1]
: (g[0] ? pow((r + g[4]) / (1 + g[4]), 1 / g[0])
: exp((r - 1) / g[2]))));
}
}

If the input to libraw is integers, the unpacked data is integers too. If the input is floating point DNG, so is unpacked data (when automatic conversion/scaling is turned off). Processed data is another story.

libraw isn't a raw converter. dcraw_emu is there for quick tests and for those who want any easy transition from dcraw to access cameras that are not supported in dcraw, and to fix some of the dcraw bugs.

Already RML used floating point for all operations after unpacking.

Thanks

Look up table.

Are you saying that this is faster than using a LUT?

image = single(image);
image = image ./ fullscale;
image = image .^ (1/gamma);
image = image .* fullscale;
image = uint16(image);

But there's enough read and photon noise to adequately dither modern 14-bit ADCs in all circumstances.

1. This thread, like a few others, is about maximising IQ by putting the maximum light on the sensor at base ISO by using ETTR as far as you can without blowing highlights.

2. Every photographer would be wise to understand this, it's simply a given fact.

3. There's difference between a maximum IQ file and a winning photograph though. (Ok ideally you'd have both).

4. Once a photographer has understood this, they can choose to make an informed decision to embrace IQ best practice strategies or choose settings that "get out of their way" that are "good enough" to nail the shot.

5. Getting the decisive moment often trumps faffing about and missing the shot.

6. This will resonate with folk who prioritise nailing the moment over a "nothing" shot that is technically superior, but useless.

7. Using this travel to USA analogy, some will choose to fly first class to their exact intended destination. Others will choose to take economy to somewhere close, maybe enjoying 10 trips or more for the price of one first class one.

8. Both approaches are valid. However, where possible, I think best practice theory should always be linked to real world strategies for execution in the field.

This is a false dichotomy. Once you understand the principles involved, including the relative effects of read and photon noise, you are free to apply them in whatever way is best for your photography.

It's not a false dichotomy. Let me explain it another way:

1. Learn and understand best practice for IQ of your file regardless.

2. Work out a way of working that best works for you.

3. If point 1 and 2 merge to be the same thing FOR YOU then that's great.

4. If point 2 turns out to override point 1 for the way you work and what you need to achieve then crack on.

5. Don't feel that you have to adopt point 1 all the time.