ICC: a sclerotic organisation obsessed by scanned imagery converted to print and controlled viewing conditions in a world where images are mostly viewed on random screens. On Mar 31, 2016 15:00, "THOMAS A LIANZA" <tomlianza@tomlianza.com> wrote:

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 in 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 (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription:

https://lists.apple.com/mailman/options/colorsync-users/edmundronald%40gmail...

This email sent to edmundronald@gmail.com

Thanks for your remarks, Tom!

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.

Which means that unsurprisingly, camera vendors build in some kind of input color appearance adjustment / scene reference → output reference conversion for an assumed typical situation, which surely makes sense because once the image is on the computer and is checked and edited (or consciously left unchanged), it is already output referred to typical computer viewing conditions. Which means that no additional color appearance adjustment is required on the output side as long as the images are not viewed in an environment that is untypically dim for a computer (i.e. << 500 lx). Which means you can simply use your ICC monitor profile as is, without any additional color appearance adjustment.

The point is this: within the sRGB world, working gamma is not necessarily equal to the encoding gamma

Which is to be expected as a “poor man’s input color appearance correction / scene reference → output reference conversion”. So “sRGB camera” means “built for sRGB” more than “built with sRGB”.

and the working gamma at different points in the process is not constant.

This I find surprising. I’m not aware of any working gamma change while you stay in the sRGB realm. Or are you referring to default printer drivers, i.e. to print output only? One final comment: A lot of the work in the field of color appearance models has been funded by companies who have a genuine interest in selling equipment. You can observe in any electronics store that “contrast sells”, i.e. if one of two otherwise identical TV sets or digital cameras produces an image with a higher contrast (within reasonable limits), the average consumer will prefer it. I’ve always felt that quite a few color appearance models tend to exaggerate the required contrast enhancements, so that they are a great alibi for camera and display vendors to sport too high a contrast by default. The “typical sRGB camera” is a good example for that. And then people who’ve grown up in our media conditioned world are surprised that the reality “isn’t as colorful as it’s supposed to be” ... Bye Uli _________________________________________________________________________ Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany http://www.ritual.org Fon: +49-700-ULIZAPPE Fax: +49-700-ZAPPEFAX _________________________________________________________________________