[Openicc] meta data in test chart

[edmund ronald]

Chris,

 I wonder whether you would consent to do a flowchart of Mac/CUPS?

 Having an architecture overview of that system (in addition to the
function documentation) would be really useful.

 Maybe someone here can suggest some flowcharting/annotation software.

Edmund


On Sat, Jan 22, 2011 at 10:23 PM, Chris Murphy <lists at colorremedies.com> wrote:
>
>
>
> On Jan 22, 2011, at 2:11 PM, edmund ronald wrote:
>
>> Maybe we should explain what happens on the Mac now:
>> - The vendor creates a driver which accepts images in a handoff space,
>> usually sRGB by default at the moment (AdobeRGB is possible) .
>> - When the user prints a picture, CUPS invokes a Colorync conversion
>> to sRGB (or AdobeRGB) and then passes the converted object to the
>> vendor's driver.
>
> One small correction is that the manufacturer driver "requests" a space based on a user setting in the print dialog, for the system to normalize the picture into. All driver settings in the print dialog are "captured" and placed into the PDF print spool file, and then CUPS hands it off to cgpdftoraster. This is a filter that leverages Core Graphics, which also leverages ColorSync. Core Graphics will have ColorSync color manage the objects in the PDF, then Core Graphics (quartz, essentially) rasterizes it, then CUPS feeds the raster data to the backend for the printer you're printing to.
>
>
>> - The vendor has very good canned profiles for the proprietary inks
>> and media, and modern inkjets are close to the average, so mostly the
>> user gets excellent prints.
>>
>> The system above is actually not a bad design, but it would be even
>> better provided the handoff space were ProfotoRGB (very wide gamut)
>> or PRNG (all printable colors), and a 16 bit conversion were
>> performed.  The big advantage of this system *as it stands on the Mac*
>> is that screens are matched to sRGB with a 2.2 gamma by default, a
>> consumer camera generates sRGB Jpeg images by default, and so there is
>> really no conversion to perform to print, simple software needs to
>> know nothing about color management, and everything is seamless.
>> Frankly one could do worse than adopt some similar method for Linux.
>> When a prosumer wants to work, with large gamuts and custom profile,
>> things get ... complicated.
>
> And this is fine, I just wish it didn't snap to these defaults, that I could set my own user defaults. And I also wish that color management in the print driver had the GUI granularity I wanted, and that it all worked so that application prematching weren't necessary.
>
> Pros are happy to go off the reservation to avoid defaults and generic results, but the present situation is clunky.
>
>
> Chris Murphy
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>