[Openicc] XICC specification draft
Michael Sweet
mike at easysw.com
Fri Jun 24 22:11:39 EST 2005
Ross Burton wrote:
> On Fri, 2005-06-24 at 02:22 +0800, Craig Ringer wrote:
>
>>I'd suggest saying that the atom doesn't have to exist, and if it does
>>not the display should be assumed to be uncalibrated. If no display
>>profile is explicitly configured, the atom should be unset.
>>
>>Stating the obvious, but you never know ... someone writing some config
>>tool might well say "or, if I don't know what profile to use, I'll just
>>set SRGB".
>
>
> Good catch, thanks. I'd forgotten to document that case (despite that
> being what my EoG patch does).
>
>
>>http://bugs.scribus.net/view.php?id=2117
>
>
> Excellent.
>
>
>>One minor issue: "As profiles can be large applications should read the
>>profile once, and cache it." Might that not become a significant memory
>>cost if ICC support is integrated into toolkits etc, so every tiny
>>application ends up reading and caching the profile? On the flipside
>>there's bandwidth and context switches, so I don't know the right
>>answer, but I thought I'd bring that up as a possible issue.
>
>
> Yes, this could be an issue. At one point I was tempted with adding
> _ICC_PROFILE_FILE, which is a filename to the profile on disk (with the
> requirements that _ICC_PROFILE must be set of _ICC_PROFILE_FILE is).
> This would save traffic if the profile was large, but wouldn't save any
> memory as (lcms at least) creates a new data structure from the profile
> data, allowing the transfered data to be deleted.
However, doing so would eliminate support for remote displays - all
remote displays would essentially be uncalibrated unless the same
ICC file existed on the local system.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
More information about the openicc
mailing list