[Openicc] meta data in test chart

[edmund ronald]

Obviously Chris is knowledgable and reasoned so I suggest we do
(mostly) as he says.

In the interests of making his points debatable, I am copying (1)-(6)
to the wiki page here

http://www.wiki-site.com/index.php/Linuxcolor

And, by the way, I think that as long as we agree that we can
color-process according to the type meta-tag in our version of CUPS, I
think exact implementation details do not matter as of today. We can
always special case certain meta-tags later, or add some if we need
them (eg. deviceN to drive an inkjet in its own non-color space)

Of course I have no idea how easy it is to make such coexist with
CUPS. The fact that no one went into CUPS to provide a profiling
method on the Mac is a very bad sign.


Edmund

On Wed, Jan 26, 2011 at 10:05 PM, Chris Murphy <lists at colorremedies.com> wrote:
> On Jan 26, 2011, at 2:38 AM, Alastair M. Robinson wrote:
>
>> 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?
>
> 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.
>
>
> And at this point I had written 9 paragraphs in response to various lines from Alastair, and my 9 paragraphs are rather repetitive so in the interest of brevity and being concise I'll use a numbered list to consolidate:
>
>
> 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.
>
> Display Default Example: I do not understand the point of the "Working Space RGB" option in the Fedora 14 System>Preferences>Color Profiles option. I suspect it means that this is a default RGB color space for any untagged RGB content encountered (by what) on the system for display or printing. I personally think this is a superfluous and specious feature. If untagged, it's sRGB. Done.
>
> Print Default Example: The sRGB / Adobe RGB / Off options we find in Epson print drivers on Mac OS and Windows. Epson will disagree with me on this because these three are proprietary color management options, they seem to be ICC but they are only front end ICC. If you choose sRGB you are using their proprietary sRGB to Epson printer+mediatype LUT. If you choose Adobe RGB you use their proprietary and wider gamut Adobe RGB to Epson printer+meditype LUT. It's actually the backend LUT that's the big difference.
>
>
> 2. Legacy applications are not injured by assuming their content is all sRGB. Presently they strip color metadata, which means the assumed source is "Display RGB" for displaying content and "Print RGB" for printing content. By assuming sRGB you actually get closer display and print results. So there's a net improvement, not a net reduction, compared to the damage they've already done by stripping/ignoring metadata.
>
> 3.  The #1 use case for a user selectable default (assumed) RGB source space is because some application in the chain has dropped either ICC, EXIF, or other color space meta data and the user has to re-attach that metadata somewhere else in the chain. I would not build a feature for the user to reinsert this metadata. Once it's dropped, just let it drop. Clearly that developer and likely that apps user, do not care about color and image fidelity or they wouldn't use that application. It isn't printing correctly now anyway, so there's no expectation for it to print any better.
>
>
> 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.
>
> 5. Applications that strip/ignore embedded ICC profiles and EXIF color space information should be purged from the planet. I am not going to advocate engineering work arounds for these applications that take time to design, build, troubleshoot, for almost no one to use.
>
> 6. Where is Linux going? What's the end game for color on the platform? Is the idea to eventually color manage every pixel? Is it going to be an opt-in or opt-out system? Deciding this makes a big difference on what language to use in GUI options, to how you allow applications to either opt-in or opt-out of color management on the platform. I'm not sure what this ideology is yet.
>
> Bottom line:
>
> I wouldn't spend a lot of time on legacy applications. Right now they suck when it comes to color. There would be a net improvement to 95% of their color display and print if you merely had the window server and printing pipeline assume everything coming from legacy applications were sRGB and then converted to Display RGB and Print RGB/CMYK accordingly. 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. If they just want more saturated prints, they should use a saturation slider in the print dialog.
>
> And in the case where you allow them to continue to be completely non-color managed, then there's no net reduction in their craptastic color fidelity, i.e. you have not made the problem worse by not handing them a life line.
>
>
> Chris Murphy
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>