: gamma bewilderment: A history lesson
: gamma bewilderment: A history lesson
- Subject: : gamma bewilderment: A history lesson
- From: THOMAS A LIANZA <email@hidden>
- Date: Thu, 31 Mar 2016 09:00:16 -0400
Hi guys,
I have been reading the various p*ssing contests on this list and being one of the older guys on this list who was actually there at the start of color management, and one of the strongest critics of the ICC in the beginning I thought that I would throw out some historical notes here. When I started Sequel Imaging in 1989, color management was just beginning. When I heard that Microsoft was planning to establish an RGB standard with Gamma 1.0, I got on an airplane and went for a meeting at Galactic Headquarters to point out just how embarrassing that decision would be to the company. I explained at the time there would probably two emerging color encoding schemes one with an assumed gamma of 1.8 and another with an assumed gamma of 2.2. As far as the Apple gamma 1.8 distinction, it wasn’t as stupid as many have assumed it to be. During the early period of Apple’s formation, Apple developed a lot of print and capture hardware that seamlessly worked with their platforms. All of this equipment was used at high background luminance’s and the evaluation of print to screen was made at insanely high view conditions. From a perceptual viewpoint, not a whole lot of research had been done at time, but Hunt and Stevens’ work was pretty well understood. Visual comparisons between monitor and print looked pretty good, although the color laser printer would alter a lot of that work, but the gamma 1.8 assumption worked pretty good for a long time. When Apple started making color output hardware, it was clear that there would have to be someway to calibrate the various color devices. That caused the development of ColorSync 1.0, which I can say, as an early adopter, worked well for the color reproduction products of the time viewed in uncontrolled environments at high luminance. Push forward to 1993 and we see the formation of the ICC with 8 founding members, all very large companies. HP and Microsoft were included in the mix, but I think they saw that the complexity that was being proposed would never work i
n the mainstream and we have, in 1996, the release of the sRGB specification. It is really important to understand that the sRGB specification is essentially an encoding specification with some peripheral documentation about the assumed viewing conditions. The sRGB spec fundamentally made color interoperable between different manufacturers and it was widely adopted very soon after introduction. In 1996, two very distinct paths of image reproduction emerged: one for consumer use(sRGB) and one for commercial use(ICC v2/v4). Between 1994 and 2001, the ICC released no fewer than 5 revisions to the specification, while the sRGB spec remained virtually unchanged, except for language changes as it moved towards ISO. As a small business owner, I was appalled at changes and the need to revise the software. Version 4.0 of the spec would finally be released as an ISO specification in 2010 roughly 17 years later. When I became Chairman of the ICC, I suggested that we move Version 4.0 into ISO (to minimize revisions) and move on to an advanced platform that could accommodate very high end activities using a full spectral workflow. This was not backward compatible with V4/V2, but it would accommodate a V4 profile in the CMM. I also directed that we provide an Open Source Reference CMM implementation to eliminate the interoperability issues of the V4 CMM’s . The latest work at the ICC has very little to do with the issues that this group focusses(obsesses) over. Now one final point about gamma and sRGB. If you take the time to actually measure the transfer function of a modern digital camera in sRGB mode, you will find that the working gamma is about 1.1-1.4 X higher than the sRGB encoding gamma. This is because the average viewer is taking the image in a high luminance environment and viewing in a low luminance environment. The print vendors tend to back this out in the print driver when working in sRGB mode. That is why a consumer level sRGB workflow actually works. In an ICC environment, a couple of things
need to happen in the profile. If you take a typical sRGB camera image and print it through a simple sRGB profile and then out to the printer, it will look dark and contrasty. This has led the ICC to build a number of appearance profiles for sRGB, but I am not aware of where that work stands. The point is this: within the sRGB world, working gamma is not necessarily equal to the encoding gamma and the working gamma at different points in the process is not constant. The complexity of the ICC specification along with the multitude of revisions have lead to interoperability issues.
Regards,
Tom Lianza
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden