[Openicc] meta data in test chart

[Chris Murphy]

On Jan 25, 2011, at 5:29 PM, Alastair M. Robinson wrote:
> OK how about this:
> 
> Applications send data in one of four classes:
> * Postscript or some other legacy format.
> * PDF with untagged image data
> * PDF with ICC-profile-tagged images
> * PDF with images tagged as DeviceCMYK or DeviceRGB, depending on which
> colourspace the driver's operating in.

Aren't 2 and 4 the same thing? It's either /device based or /ICCbased. I think that's why there's a metadata usage case for ICC profile targets that goes above and beyond /device to confirm we literally mean device space, not merely untagged which will require an assumed source.

> 
> The last two variants are easy to handle: tagged images should be
> converted to the printer's profile, while DeviceXXX images should be
> passed through unmolested (provided they match the driver's colourspace
> - if not the job needs to fail; silently converting would make
> diagnosing problems much harder.)

For ICC profile targets, yet. For everything else, something needs to be assumed if untagged and then go with it. If it's important enough, people will tag their content correctly and applications will preserve the tags. If not, then the application is a saboteur in the workflow and shouldn't be used if you care about image quality.

> 
> For legacy Postscript and Untagged PDF I think we need an option
> provided by the print subsystem, be it CUPS, the PPDs, the CPD or whatever:
> "Default Colour Interpretation: [sRGB  |  AdobeRGB  |  Device Native]"
> This describes the colourspace in which input data is assumed to be.

I'm not going to put up a big complaint to stop this if this is what you guys really want. But my two cents is this is a sloppy workflow on Windows and Mac OS right now. It's stupid that this isn't self-configuring based on what's in the PDF print spool file. I think this is a legacy behavior, and not a good behavior to re-invent or mimic.

It's not good for the single image, because the single image is either tagged or not tagged. If tagged it should always have the profile honored, and that is the default interpretation. If untagged, it should be assumed to be sRGB. There is no other rational choice right now for assuming source spaces for untagged content. Asking users to guess isn't a quality conscious workflow either.

It's definitely not workable for documents containing multiple objects which may have multiple sources: again the only proper way to deal with it is to use the embedded profile, and if none, then assume sRGB.

One possible open question is what CMYK space to assume if we run into it. This could be a regional preference, and by that I actually mean the region the image originated in, not the region it's being printed in. A CMYK image originating from the U.S. would almost certainly be a SWOP image, and one originating from Japan would be using one of the standard Japan CMYK profiles shipping with Adobe products, and one originating from Europe - well that's a chore to guess what the source may be, but maybe there's a lower chance of encountering untagged CMYK images from European sources...FOGRA27 otherwise?


>  By
> default it would be set to sRGB, so J. Random User will get the expected
> results (provided a profile is available for his print settings) if he
> just prints a photo without setting anything up, but the queue can be
> set unambiguously to Device Native for profiling purposes.

a.) If you honored EXIF data, he will get what he expects regardless of whether his camera is set to shoot sRGB or Adobe JPEGs, or he mixes them.

b.) If you don't honor EXIF, or embedded profiles, and have the architecture you describe (which exists now on Mac OS and Windows), you now have to treat the image one of two ways:

Mac OS: Even odds the printing application is smart enough to pass on an ICC profile onto the printing system, which will then convert it to sRGB and then hand it off for printing. This intermediate conversion is really unnecessary.

Windows (and many other Mac OS apps esp when it comes to EXIF color spaces): The embedded profile is ignored. The image is not converted to sRGB, but is assumed to be sRGB, guaranteeing that unless it was sRGB in the first place, that it will print incorrectly.

So again, I think this is not a good workflow. It's as bad as what we have now.


> The fly in the ointment is what to do about PDFs with icc-profile tagged
> images when the queue's in Native mode.  Personally I'd be in favour of
> rejecting such jobs outright than trying to do anything "clever".  An
> outright failure to print is much easier to diagnose than corrupted
> profiling test charts caused by a rogue conversion.

I would not have a GUI option to define the color management behavior of the printing pipeline. The PDF print spool file (and/or its job ticket) should do it.



Chris Murphy