[Openicc] meta data in test chart

[Alastair M. Robinson]

Hi :)

On 26/01/11 21:05, Chris Murphy wrote:

> I'm referring to the structure of the PDF. PDF, as far as I know, does not have a means of differentiating between your case 2
> and case 4. Untagged = /deviceRGB and/or /devicecmyk.

Well I have to say I don't know that much about PDF, so please do 
correct any misunderstandings on my part :)  But as I understand it 
there are different levels of PDF with increasingly complete support for 
tagging objects with ICC profiles?  I see a semantic difference between 
an older PDF with nothing tagged and a newer PDF with objects 
specifically tagged as /device[RGB|CMYK].

> 1. I oppose a user selectable default (assumed) RGB source space for untagged content. I think it's a confusing and useless
> option. There's statistically zero instance of naturally occurring RGB images that are both untagged but improperly described
>  by sRGB.

So which application would you use, under Linux, today, to print out a 
profiling chart, secure in the knowledge that the image data was 
correctly tagged and would be unmolested by our proposed workflow?
As for AdobeRGB being superfluous in my proposed option, yes, you're 
probably right there,

> 4. Simple is better. The lesson to learn from Mac OS is that complicated architectures are difficult to create, manage,
> and get support from other people who need to make various parts like the PPDs and print drivers. If you hang too many
 > complicated dependencies (especially undocumented or poorly 
documented ones) then it's a problem. Avoid this, and avoid the problem.

I'm more worried about inscrutable smarts happening behind the scenes - 
that's what's caused the dissatisfaction on the Mac.  Hence my desire 
for an explicit "leave my colours the hell alone" switch, rather than it 
being an automatic user-invisible thing that happens only if an 
application does the Right Thing.

> 5. Applications that strip/ignore embedded ICC profiles and EXIF color space information should be purged from the planet.

Definitely! :)

Sadly, they won't be.

> You don't need GUI choices for this. These apps are not intending to draw in Adobe RGB (1998) so there's no reason to have
> a GUI option allowing the user to do it.

Fair enough - I only mentioned AdobeRGB as an option since someone else 
had already mentioned it as a possible handoff space - my main intention 
was the sRGB / None distinction.  If people think even that's 
superfluous then fair enough, provided we find a robust, scrutable and 
easy-to-trace-and-diagnose-when-things-don't-work-as-planned way of 
passing pretargetted image data to the printer.

All the best
--
Alastair M. Robinson