Honestly, I've stopped engaging with him directly out of respect, as I suspect something more sinister is at play - a condition which I don't wish upon anyone. I don't know what he was like a few years ago as a person, but I cannot believe anyone could be so irrational and abrasive and at the same time be able to function in a team or hold a job where scientific and mathematical rigour are paramount.
Having a spirited discussion is one thing - it can be quite healthy and furthers understanding of both participants and observers. But denying simple facts is just downright bizarre. I don't want to see this thread devolve into along whinge or b***h-fest, as that is improper behavior, unconstructive and not the purpose of this forum. I will just give a small example of how I've spent many, many hours trying to teach(?) him a basic fact, to no avail.
As we all know, RAW converters such as DCRAW, by default and unless you specifically turn this off, perform a stretch in order to convert the linear data (e.g. photon count) into something that matches the non-linear response of the various rendering devices (e.g. a screen). Again, we all know this. Roger does not that dispute that.
However, for reasons unknown, Roger does dispute that the typical stretch (aka non-linear transformation function) conforms to the BT.709 or sRGB standards, because that's what our devices are based on and require. It's fine if you want to debate something. It's not fine (or rational) if you deny 3rd party sources such as the actual DCRAW manual, help text, source code and black box behaviour
, along with a myriad of other sources that confirm that, yes, the standard non-linear transformation function to make linear data non-linear, is encapsulated in the BT.709 or sRGB standards (there are some other profiles as well).From the DCRAW manual
From the Wikipedia on the sRGB standard;
- Code: Select all
"-g power toe_slope
Set the gamma curve,** by default BT.709 (-g 2.222 4.5)**. If you prefer sRGB gamma, use -g 2.4 12.92. For a simple power curve, set the toe slope to zero."
- Code: Select all
"LCDs, digital cameras, printers, and scanners all follow the sRGB standard."
In a last ditch effort to convince him that David Coffin (the author of DCRAW) is not a liar, and that the many different sources on sRGB and BT.709 are not part of a conspiracy, I even wrote some publicly available software with full source code
to analyse DCRAW's behaviour as if it were a black box; reverse engineering the modification of each brightness level of DCRAW's input vs the output and plotting the result
. It comes as no surprise to anyone that the curve thus plotted exactly matches the BT.709 transformation curve.
My thanks for all this effort? I'm now an "Internet Troll" in one of his "articles".
The reason why we were "discussing" non-linear transformation curves in the first place? His attempt to derail a discussion about his mathematically incorrect insistence that it's perfectly ok to perform linear operations (such as light pollution subtraction) on non-linear data, "because you can't see the difference".
Just like you "can't" see the difference if you take this linear image;
Add some light pollution;
And try to use his "method" of stretching first (I used a gamma 2.2 which, for all intents and purposes yields the same as a sRGB conversion) and then moving the black point to subtract the light pollution.
Nope. Can't see the problem here at all.
EDIT: And here is an interactive graph
for peer-review that I built that demonstrates the math, and the difference between subtracting light pollution before and after stretching. That is, if you accept that Norman Koren (Imatest author), is not in on the conspiracy-against-Roger when he says that; "On the encoding side the "ideal" is pixel level = scene brightness ^ (encoding gamma), where encoding gamma = 1/display gamma
". (note that this is the formula being used for gamma correction in the graph)