On 03/13/2010 02:41 PM, 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. > > If such device dependent files end up anywhere but in the printer spooler's temporary > 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... > > 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. > > 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? I think the answer is easy: provide a way to strip the color profile. If a person is specifically targeting a situation where a color profile is a bad thing, they strip it, et voila. Otherwise, everything has a color profile, unless it lacked one when it was imported. And seriously, 3kB for a profile is peanuts for most images. If you know you are trying to squeeze the size of your images, you get rid of the color profile. Otherwise, the image is probably going to end up north of 50 or 100kB anyway, at which point again, 3kB is peanuts. Let's not overthink this. This isn't to say that a "web export" functionality wouldn't be useful. Just that thinking about in the context of this discussion will probably turn into wasted cycles. --xsdg _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
