> Graeme Gill wrote:
>> The bottom line is that it depends on your purpose. If you
>> have a particular reason to specify device dependent colors,
>> then you deliberately don't want to tag the file with a profile.
> This case worries me a bit. Hope you can enlighten me what the best practices
> In a way, it is paradoxical that the files which, among all files, depend the
> on color profiles, are the files which do not get profiles embedded.
I don't know what you mean by this. You either have a file that has a specific,
device independent color specification (either by using a device indepenedent
color space, or by using a device dependent colorspace + a device color
profile), or as a special case, you label a files as being "in the output
native space". Ideally there would be a special flag for this,
but a defacto "flag" is not to tag the device dependent colorspace.
[Apple made the mistake in many of their systems on insisting on every
file be tagged, and substituting a default tag if one was missing. They
suggested that the way to label a file as being in the output devices space
was to tag it with the output devices profile. The flaw is that you may
not know the output devices profile or have access to it at the time the
file is created, or the devices profile may change between when you create
the file and it is sent to the devices. Tagging a file with a devices profile
is not the same as saying "it's in whatever the devices native space is at
the time it is displayed/printed". Apple got into big trouble with this very
approach with the release of OS X 10.6, when suddenly people couldn't profile
> If such device dependent files end up anywhere but in the printer spooler's
> directory, i see that as an invitation for trouble.
> Great fun for the collegue who gets
> assigned to print those ten images i tailored for three different printers --
> and now i
> have to leave in a hurry...
I don't follow you. In a color managed workflow the meaning on an un-tagged
file is that it is in the native output space. The purpose is to exercise
that native output space for calibration, profiling or diagnostics.
If you want a color printed that doesn't depend on the output device,
> On the other hand, it seems ridiculously wasteful to embed a printer's
> profile into a file
> which gets send to that very printer anyway. Referencing an URL seems a good
> solution here.
> This probably also holds true for the case, where images get optimized for a
> photo finisher
> who provides regularily updated profiles of his minilab.
Again, I'm not following you. You can't assume the file is in the native
devices space. The point of tagging it is so that it can be converted to
the printers space. Using URL's are fragile, and introduce dependencies.
> But how to avoid the overhead when such files are to be archieved?
> After all, URLs tend to throw 404s after a while.
> Just rely on the compression feature of the backup software?
Embed the profile. Problem solved.
Gimp-developer mailing list