You did.
"if you display a linear (gamma 1.0) image on a standard monitor configured in a conventional manner (gamma approximately 2.2); using equipment and software as setup for normal average typical everyday digital still camera use, the resulting displayed image will have its final gamma out of balance and tend to look flat and dark. "
If I display an image corrected for gamma = 2.2 on a gamma = 1 monitor system, it'll look too light. So what?
I did. We all work within our own individual assumptions. And so...
I assumed and wrote what you've quoted because it aligns with the context and lies within the scope, breadth, depth, target audience, and topics which were mentioned and addressed in the article from my perspective. I'm not trying to expand the context of the article beyond "using equipment and software as setup for normal average typical everyday digital still camera use" — why would I? What logic or common sense would suggest assuming otherwise? This article was not a submission to the ICC on color managed workflows. It was a three-page brief overview of a different topic for novices which necessarily limited its scope.
Why would I assume the article was meant to embrace, within its very brief limited boundaries, anything other than common uses, equipment, setups, or methods? That other path leads straight into the weeds. I'm happy to just stay in the short grass when reading this type of article — or discussing it.
By the time that article was written, a color managed workflow was the standard. The ICC had won years before, in part thanks to Bruce. Assuming a non-color managed monitor was not assuming a normal use case.
The article never mentions color managed workflows or color management. There are still a number of people taking photos blissfully unaware of how color is automatically managed for them with every shot.
For those that did or have setup a color managed work flow, the equipment and software as setup for normal average typical everyday digital still camera use still hasn't changed and still includes calibrating a monitor to around 2.2 gamma since the defaults in hardware and software by design and convention automatically assume that display standard.
At least, that's what my weed wacker told me. It also said that conventional computer systems assume a standard monitor gamma of 2.2 as well.
In a color managed workflow, displaying a gamma 1 image on a gamma 2.2 monitor won't display darker than intended colors. You'd have to break the color management for that to happen.
BTW, I do almost all my Matlab image processing in linear color spaces. It makes most algorithms for manipulating images simpler. I normally use double precision floating point. Lightroom's standard internal color space is linear, too, with the PPRGB primaries, but not its gamma of 1.8.
The article never mentions color management or color managed workflows. It's the topic you want to discuss, but it isn't included anywhere in the article.
It was the gold standard for image editing in that era. If you were looking at images with color management broken, you'd expect them to not look right. No surprise there.
Where is color management ever mentioned in the article?
Kinda my point. Bruce argued for years that a color managed workflow was the way to go. The ICC won that battle, with the help of popularizers and teachers like Bruce and Andrew. Then to publish a paper after the battle was over and color management was the standard that assumed no color management in the workflow is very strange.
But there's a bigger issue here. Bruce -- and others, to be sure -- paid way to much attention to the precision of raw files, and this article is an example. As a result, we got users demanding, and camera manufacturers producing, cameras that had precision that made no sense at all, like my Hasselblad H2D-39 CCD camera with16-bit raw file precision, at least 5 bits of which was pure noise. That was silly, and they marketed the heck out of that.
I'm not quite sure Bruce wrote that article.
I'll bet Jim King didn't have anything to do with it.
Well, the blunders in the article are very uncharacteristic for Bruce. So was him ignoring my e-mail.
What else can be brought up that is never mentioned or discussed in the article?
Yep. There's no discussion of the precision of raw files in the article either. There's no mention of precision whatsoever.
Is this the new topic you want to hammer which is never mentioned in Bruce's article? It would take a very long time to discuss all of the topics never mentioned in his article — but, it's your time and energy to use as you like.
That's not true at all. He looks at results for a raw file of 12-bit precision that he specifies. He gives numbers related to how many levels there are in various regions based on that precision. Did we read the same article?
en.wikipedia.org/wiki/Precision_(computer_science)
Insinuations regarding authorship and my email was ignored definitely signal the end of the line for me on this rollercoaster.
Appears to be the new nail with the same hammer.
I read the article. It discusses how levels are distributed.
You won't find mention of precision anywhere in the article because that's not the context within which levels were discussed. The quantity and precision of levels are the same in his comparisons, it's the difference in how they are distributed which is the topic discussed — not any difference in their precision.
But, there's no reason to take my word for it. Readers can read the article for themselves to see what the topics are being discussed.
12-bits is a measure of precision.
Welcome back.
