[Openicc] meta data in test chart

[Alastair M. Robinson]

Hi :)

On 26/01/11 02:09, Chris Murphy wrote:

> 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.

Effectively, yes, but how we'd deal with would differ - the 
explicitly-marked /device stuff should not be converted even if there's 
a viable output profile, whereas the merely untagged stuff should. 
Also, the granularity is different - in case 4 the type of image can be 
set on a per-object basis in the PDF, yes?

> For ICC profile targets, yet. For everything else, something needs to be assumed if untagged and then go with it.

Yes - my argument is that *what* is assumed needs to be selectable, 
because trying to make an automated guess is what's causing people such 
grief on the Mac.

> 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.

I'm confused - isn't the complaint with the Mac precisely that you 
*can't* explicitly specify that image data should be left the hell alone? :D

Anyhow, I'm just trying to get the ball rolling again here, so if you 
can suggest a superior workflow, in concrete enough terms for it be 
actually *implemented*, please do ;)

> 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.

You're more optimistic than I am about how long it will take 
applications to support tagging images as /DeviceXXXX - remember our 
printing's still almost exclusively Postscript based at the moment.

> 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.

OK, well I don't mind if I can't specify AdobeRGB as an assumed input 
space - but I do think we need an explicit switch between assuming 
untagged input is sRGB and Device values.

> 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?

Good point.

> 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.

Yes, that's what I'm trying to avoid - the need for a handoff space. 
The sRGB / AdobeRGB / Device space switch I suggested is a default input 
space, not a handoff space.

> 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.

And with my suggestion this will be the case only for legacy 
applications which can't tag an image with a profile.  It'd be a mistake 
to underestimate how long we'll be dealing with legacy applications, 
however.

> 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.

Well yeah, the option would probably be implemented by setting a job 
ticket in the spool file - when I said GUI option I simply meant that it 
needs to be exposed to the user in some form.

Anyhow, like I said, I'm just trying to get the ball rolling again, 
since this discussion's been going round in circles for a while now!

All the best
--
Alastair M. Robinson