yahvuu wrote: > 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 are. > > In a way, it is paradoxical that the files which, among all files, depend the most > 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 devices 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 printers anymore.. ] > If such device dependent files end up anywhere but in the printer spooler's temporary > directory, i see that as an invitation for trouble. Why ? > 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, tag it! > 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. Graeme Gill. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
