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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to