GIMP distributing sRGB profiles: license issues?

Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles
to the GIMP distribution. They're 3kB each, so size shouldn't be an
issue. The main question is one of licensing. I believe the license
allows us to distribute the profiles, but IANAL.

I'd appreciate if someone who either is a lawyer, or acts in that
capacity for GIMP, could comment. If you have other issues with the
patch, feel free to voice those as well.

The patch is attached, and also lives in bugzilla at:
https://bugzilla.gnome.org/show_bug.cgi?id=608961#c2

--xsdg

Omari Stephens wrote:
> Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles
> to the GIMP distribution. They're 3kB each, so size shouldn't be an
> issue. The main question is one of licensing. I believe the license
> allows us to distribute the profiles, but IANAL.

As I mentioned before, the sRGB profile provided in Argyll is
public domain.

Graeme Gill.

On Thu, 2010-03-04 at 19:49 +0000, Omari Stephens wrote:
> Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles
> to the GIMP distribution. They're 3kB each, so size shouldn't be an
> issue. The main question is one of licensing. I believe the license
> allows us to distribute the profiles, but IANAL.
>
> I'd appreciate if someone who either is a lawyer, or acts in that
> capacity for GIMP, could comment. If you have other issues with the
> patch, feel free to voice those as well.

I appreciate your work on this, but I am afraid that the license is
compatible with the GPL. Aside from that I wonder why GIMP should ship
with color profiles at all. There is the icc-profiles package that seems
to be available in most Linx distributions nowadays. We should rather
continue to depend on that package and make sure that it is included
with the Windows installer than installing our own duplicates.

The folks from the OpenICC initiative [1] are trying hard to push shared
color profiles and color management work-flows. We should really try to
cooperate instead of building our own little world.


Sven

[1] http://lists.freedesktop.org/mailman/listinfo/openicc

On 03/04/2010 09:01 PM, Sven Neumann wrote:
> On Thu, 2010-03-04 at 19:49 +0000, Omari Stephens wrote:
>> Hi, all. I just finished v1 of the patch to add the sRGB ICCv2 profiles
>> to the GIMP distribution. They're 3kB each, so size shouldn't be an
>> issue. The main question is one of licensing. I believe the license
>> allows us to distribute the profiles, but IANAL.
>>
>> I'd appreciate if someone who either is a lawyer, or acts in that
>> capacity for GIMP, could comment. If you have other issues with the
>> patch, feel free to voice those as well.
>
> I appreciate your work on this, but I am afraid that the license is
> compatible with the GPL.
I presume you meant "isn't compatible." Obviously, IANAL but from
re-reading the GPL, I believe the case of including a color profile (any
color profile) falls under its discussion of aggregates:

A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work, and
which are not combined with it such as to form a larger program, in or
on a volume of a storage or distribution medium, is called an
“aggregate” if the compilation and its resulting copyright are not used
to limit the access or legal rights of the compilation's users beyond
what the individual works permit. Inclusion of a covered work in an
aggregate does not cause this License to apply to the other parts of the
aggregate.

> Aside from that I wonder why GIMP should ship
> with color profiles at all. There is the icc-profiles package that seems
> to be available in most Linx distributions nowadays. We should rather
> continue to depend on that package and make sure that it is included
> with the Windows installer than installing our own duplicates.
My goal in this is only to make sure than an sRGB profile is guaranteed
to be available. Depending on the icc-profiles package or any other
option (such as using Graeme's profiles) would be perfectly fine, as
long as I could assume that an sRGB profile is available (and there is
some way to get its pathname).

> The folks from the OpenICC initiative [1] are trying hard to push shared
> color profiles and color management work-flows. We should really try to
> cooperate instead of building our own little world.
> [1] http://lists.freedesktop.org/mailman/listinfo/openicc
I was unaware of this. Again, the goal is to be able to assume that an
sRGB profile is available, regardless of how that guarantee is carried out.

Finally, to respond to your question on the bug, we need some way to
embed an actual sRGB profile into an image. Simply leaving an image
untagged or adding some sort of sRGB tick-mark isn't sufficient — there
are formats where the color-profile is all you have (TIFF and PDF come
to mind), and where it _isn't_ appropriate to assume that every untagged
image is sRGB.

As one very specific example, I have a print shop (bayphoto.com) whose
printers' native color space is AdobeRGB. If you send them an untagged
sRGB image, it'll likely end up wrong. And even beyond that, there's
the question of whether an sRGB image is sRGBv2 or v4 — the spec openly
acknowledges that the two will behave differently in many circumstances.

--xsdg

Hi,

On Fri, 2010-03-05 at 07:34 +0000, Omari Stephens wrote:

> Finally, to respond to your question on the bug, we need some way to
> embed an actual sRGB profile into an image.

Can't we just embed the lcms built-in sRGB profile? That sounds like a
totally straight-forward solution. But I might have missed something. Is
there a particular reason why we need the profile to exist as a file?


Sven

On 03/06/2010 12:58 PM, Sven Neumann wrote:
> Hi,
>
> On Fri, 2010-03-05 at 07:34 +0000, Omari Stephens wrote:
>
>> Finally, to respond to your question on the bug, we need some way to
>> embed an actual sRGB profile into an image.
>
> Can't we just embed the lcms built-in sRGB profile? That sounds like a
> totally straight-forward solution. But I might have missed something. Is
> there a particular reason why we need the profile to exist as a file?

So, you're right; I had dismissed this possibility out-of-hand without
investigating sufficiently. Having poked around the lcms code a bit, I
don't think this option is feasible.

Basically, lcms generates an RGB profile with the sRGB primaries,
transfer functions (aka "gamma curve"), and whitepoint; for the curious,
this happens in cmsCreate_sRGBProfile() in cmsvirt.c . For one, I'm not
sure if this is all there is to a "real" sRGB profile (although it
certainly might be; thoughts, Graeme?).

Secondly, even if that's all there is to it, there doesn't seem to be a
way to get a profile _out_ of lcms. The prototypes for profile
input/output are limited to cmsOpenProfileFromFile(),
cmsOpenProfileFromMem(), and cmsCloseProfile(). Nothing about exporting
a profile in any way.

--xsdg

Hi,

On Mon, 2010-03-08 at 05:53 +0000, Omari Stephens wrote:

> So, you're right; I had dismissed this possibility out-of-hand without
> investigating sufficiently. Having poked around the lcms code a bit, I
> don't think this option is feasible.
>
> Basically, lcms generates an RGB profile with the sRGB primaries,
> transfer functions (aka "gamma curve"), and whitepoint; for the curious,
> this happens in cmsCreate_sRGBProfile() in cmsvirt.c . For one, I'm not
> sure if this is all there is to a "real" sRGB profile (although it
> certainly might be; thoughts, Graeme?).

It is a "real" sRGB profile. If you look at the color management code in
GIMP, you will notice that we use this built-in sRGB profile and that we
even do an MD5 hash comparison against it to find out whether an
attached profile is an sRGB profile. This is done to avoid a needless
conversion from one sRGB profile to another identical sRGB profile.

> Secondly, even if that's all there is to it, there doesn't seem to be a
> way to get a profile _out_ of lcms. The prototypes for profile
> input/output are limited to cmsOpenProfileFromFile(),
> cmsOpenProfileFromMem(), and cmsCloseProfile(). Nothing about exporting
> a profile in any way.

Since the in-memory representation you get from cmsCreate_sRGBProfile()
has the same MD5 sum as an sRGB profile opened from disk, it appears
that it should be sufficient to use g_file_set_contents() to write it to
disk (if that is needed at all). Or to use gimp_parasite_new() to create
a parasite from it (which is more likely what you will want to do).


Sven

On Mon, 2010-03-08 at 08:52 +0100, Sven Neumann wrote:

> Since the in-memory representation you get from cmsCreate_sRGBProfile()
> has the same MD5 sum as an sRGB profile opened from disk, it appears
> that it should be sufficient to use g_file_set_contents() to write it to
> disk (if that is needed at all). Or to use gimp_parasite_new() to create
> a parasite from it (which is more likely what you will want to do).

Or perhaps not. We are just creating the check-sum over the profile
header and for the built-in sRGB profile we use a hard-coded known
check-sum. So it remains to be investigated if the built-in sRGB profile
could be attached to an image and then successfully saved with an image.
It should be a simple change to plug-ins/common/lcms.c to actually make
it attach the sRGB profile. Perhaps you could give that a try and see
what happens?


Sven

Omari Stephens wrote:
> Basically, lcms generates an RGB profile with the sRGB primaries,
> transfer functions (aka "gamma curve"), and whitepoint; for the curious,
> this happens in cmsCreate_sRGBProfile() in cmsvirt.c . For one, I'm not
> sure if this is all there is to a "real" sRGB profile (although it
> certainly might be; thoughts, Graeme?).

It's probably sufficient for basic sRGB functionality, but it's not
complete in the formal sense (ie. missing information tags
as to viewing conditions etc., that some CMM's may use.)

Graeme Gill.

I am still trying to get my head around this subject / thread.

In various places (not necessarily in this thread) there is discussion
of "embedding profiles" and "tagging with color space". It is NOT clear
to me if these are two phrases with the same meaning.

As I recall, the OP brought this overall subject up due to serious
issues he was having with his target audience. It was not clear to me
if his problems were problems for all audiences. (As I recall, his
issue related to color in artwork not matching defined color names of
elements in web pages.)

>From my reading, especially of G. Ballard of www.gballard.net
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html
http://www.gballard.net/psd/save_for_web_embed_ICC_profile.html

Ballard is emphatic that images for web use should *NOT* have "embedded
profiles" and should *NOT* be "tagged with a color space" except under
unusual circumstances.

His demonstrations are worth a look. (However, I wish his writing was
more precise and less repetitive.)

At the BOTTOM of this message I quote something he says buried on
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html


............... So what I want to understand is .........

- In Gimp, I understand that an image without an embedded color space is
treated as if it had an embedded sRGB color space.

- BUT, when that image (without a previously embedded color space) is
edited and saved in Gimp, is there any "embedding" or "assigning" or
"tagging" of color space being done it the user does not explicitly
assign a color space?

- And do the words "embedding" or "assigning" or "tagging" mean the same
thing in this context?

- In a previous discussion it was suggested that round-tripping using
tifftopnm and pnmtotiff would remove color profile parasites that might
exist for whatever reason. Is this still the best method?

- What is it that I am missing about this subject? I feel like I am
missing something important, but I don't know quite what.


[I currently use approximately 20,000 BASE images (each in four sizes,
thus 80,000 potentially) spread over 1975 web pages. When my site is
"done" (never), it will be closer to 6000 web pages, unless I get
ambitious. For my products (postage stamps) color is an important issue
-- sometimes the difference between a light-dark-blue-green stamp and a
dark-light-blue-green stamp can be $100 in value (or more) and a sale vs
no sale.]


================

QUOTING G. Ballard

EMBEDDING ICC PROFILES
in internet photos and graphics:

While Safari for Windows-based computers makes color-managed web
browsers more common, this professional webmaster will continue to strip
ICC profiles from 99 percent of the digital photos he publishes, mostly
because adding color profiles increases file sizes, about 4K per photo.

Multiply that by the number of slices contained in the picture or how
many web graphics are in a web page and the download size and time to
load the page greatly increases.

I believe the future of embedding ICC profiles on the internet is more
in line with Windows Vista because it already treats untagged color as
sRGB and thereby doesn't need color tags to display web color properly.

I base my professional internet publishing workflows on facts 1) sRGB
srgb.icc is arguably the default color space of the internet, and 2)
sRGB (standard red green blue) is the target color space of the world
wide web intranet.

END QUOTE

================

Jay Smith wrote:
> In various places (not necessarily in this thread) there is discussion
> of "embedding profiles" and "tagging with color space". It is NOT clear
> to me if these are two phrases with the same meaning.

In general they are the same thing. Some people have schemes
to tag a file with a symbolic profile or URL, but these
schemes are less robust (it needs to be a "well known" space
or you need net access to interpret the colorspace). An
embedded ICC profile is an unambiguous way of tagging it.

>>From my reading, especially of G. Ballard of www.gballard.net
> http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html
> http://www.gballard.net/psd/save_for_web_embed_ICC_profile.html
>
> Ballard is emphatic that images for web use should *NOT* have "embedded
> profiles" and should *NOT* be "tagged with a color space" except under
> unusual circumstances.

Lots of people have lots of opinions. Serious color people often call
untagged raster files "mystery meat" though, and shake their heads.

> His demonstrations are worth a look. (However, I wish his writing was
> more precise and less repetitive.)

His website is a bit hard to follow.

A lot of his advice is along the lines of "it's not fully supported
so it doesn't work so don't use it", but of course this is chicken
and egg stuff. He's busy pushing sRGB, while others are railing
against the loss of quality of having everything squashed though sRGB!
[Note that his rant about Apple is largely moot now, since they
have switched to Gamma 2.2 and assuming un-tagged = sRGB with OS X 10.6 ]

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.
You may be working around limitations of other elements (for instance,
say a plugin like flash doesn't honour embedded profiles, and
you want to match an image to certain colors displayed by the plugin),
but if you want to convey actual color, then tagging the image
with the colorspace (or using a device independent color representation
like L*a*b*) is the right way to do it. If you want maximum compatibility,
convert to and tag with sRGB. If you want minimal loss of gamut and
don't care about compatibility with non-color managed applications,
you might choose some other colorspace.

Note that in an age of very wide gamut displays, even things like GUI
elements need color managing, if the GUI isn't going to look accidentally
garish, and that un-tagged images may look kind of ridiculous if
the (even color managed application) assumes that un-tagged images
are the output device space.

> QUOTING G. Ballard
> ICC profiles from 99 percent of the digital photos he publishes, mostly
> because adding color profiles increases file sizes, about 4K per photo.

Hmm. I'm not sure that 3k for an image is really that significant
given the bloat and slowdown on typical websites due to flash,
advertising re-direction, Web 2.0 etc. etc.
Even the small images on his website are 35k, so 3k for an sRGB profile
is about 8% - hardly noticeable. The moves to use URL references is
one aimed at reducing the overhead, but I wonder if it is worth the
trouble and breakage it will cause.

Graeme Gill.

On Wed, 2010-03-10 at 16:36 +1100, Graeme Gill wrote:
[...]
> Hmm. I'm not sure that 3k for an image is really that significant
> given the bloat and slowdown on typical websites

Some people (including me) go to quite a bit of trouble to make the
initial Web page load as quickly as possible. It makes a huge difference
to the user experience.

Sure, 3K isn't much. 20 icons on the page? 60K. Dialup? An extra ten
seconds. A lost customer, sometimes. An option to embed, refer, or
neither, makes sense to me, because you can't predict which is wanted.

> [...]

> The moves to use URL references is
> one aimed at reducing the overhead, but I wonder if it is worth the
> trouble and breakage it will cause.
It sounds like if it's done right it will be an improvement.

The point of the Web has been summarized as, "let's see what happens
if you give everything a name."

Liam

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?


regards,
yahvuu

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

Omari Stephens wrote:
> On 03/13/2010 02:41 PM, yahvuu wrote:
>> 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.

I fully agree that this a sound overall strategy for GIMP, and probably
this is all that is necessary from GIMP's side.

However, creating unmanaged files that aren't sRGB is a dangerous thing to do,
and releasing such uninterpretable files to the world should really be avoided.
I think it helps to understand the scenarios where people are tempted to create
such files -- maybe there's something that can be done to not create that temptation
in first place. Hence my question how to best deal with printer dependent data.


> And seriously, 3kB for a profile is peanuts for most images.

I had to learn that measured profiles turn out be a lot bigger. The minilab
profiles i've seen are >= 1MB.


regards,
yahvuu

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.

Hi,

On Tue, 2010-03-09 at 22:22 -0500, Jay Smith wrote:

> ............... So what I want to understand is .........
>
> - In Gimp, I understand that an image without an embedded color space is
> treated as if it had an embedded sRGB color space.

Not completely. It is assumed to be in sRGB. That assumption means that
the display code (with color management enabled) will use the sRGB
built-in color profile to interpret the image data. The image still does
not have a profile attached and that makes a difference when it is
saved. What exactly happens when it is saved depends on the file format
you are saving to.

> - BUT, when that image (without a previously embedded color space) is
> edited and saved in Gimp, is there any "embedding" or "assigning" or
> "tagging" of color space being done it the user does not explicitly
> assign a color space?

As said above, this depends on the implementation of the file export
plug-in. IIRC pretty much all file plug-ins will not tag or embed
anything if the image does not have a color profile attached. The PNG
plug-in however will tag the image with an sRGB tag. It does not embed a
color profile, it just sets a flag saying that the image should be
interpreted as sRGB. This particular behavior of the PNG plug-in is
debatable and could be considered a bug.

> - And do the words "embedding" or "assigning" or "tagging" mean the same
> thing in this context?

No, but that should have become evident already.


Sven

On Wed, 2010-03-10 at 09:14 +0100, Sven Neumann wrote:

> > - And do the words "embedding" or "assigning" or "tagging" mean the same
> > thing in this context?
>
> No, but that should have become evident already.

Let me try to define the terms nevertheless. Perhaps that helps to clear
up some of the confusion around this topic.

We speak about an embedded color profile in the context of an image
file. The file contains a color profile and this profile defines how it
should be interpreted. Not all file formats actually support this.

We speak about assigning a color profile in the sense of assigning the
"icc-profile" parasite to an image object in GIMP. This is what a file
load plug-in will typically do. If it finds an embedded color profile in
the image file, it will create an "icc-profile" parasite from that
profile and attach it to the image. This attached profile will be used
by the display code to correctly display the image and when that image
is exported, the file save plug-in may embed the attached profile in the
file that it creates.

Some file formats, such as PNG for example, allow to tag the file to be
in a particular well-known color space. The color profile is not
embedded then, it is assumed to be well-defined. Instead of distributing
the profile with the image file, there is just a flag saying "this data
should be interpreted as sRGB".


Sven

On 03/10/2010 02:37 AM, Sven Neumann wrote:
> Some file formats, such as PNG for example, allow to tag the file to be
> in a particular well-known color space. The color profile is not
> embedded then, it is assumed to be well-defined. Instead of distributing
> the profile with the image file, there is just a flag saying "this data
> should be interpreted as sRGB".

Ah, so the color problems I am having with images created by Gimp are
due to the PNG files being 'tagged' as sRGB. The color profile isn't
embedded to the image, it's just specified and, since it's a well known
color profile, any program that attempts to display the image will do so
as though the PNG had an embedded sRGB profile. Thanks for pointing that
out.

To summarize:
Tagging is great because it specifies a color profile without increasing
the image file size. Assuming that the destination system applies the
correct profile.

Embedding is great because you have greater flexibility for an endless
variety of custom color profiles.

The end result of the two is the same though: the image will be color
managed.

----------------------

As for gballard's recommendation for not including color profiles in web
images: He's only saying that because his ultimate goal is color
consistency across all platforms/browsers.

I, as a professional web designer, think he's right when it comes to
page element images that are intended to match colors defined in HTML or
CSS. Otherwise all of the Safari users that visit your site are going to
doubt your design capabilities. For photographs I think it's fine to
include color profiles. Browsers that don't color manage are going to
show you the same limited gamut either way, but browsers that DO color
manage will display an enhanced image with a wider gamut of colors.
Progressive enhancement.

You do have to also keep in mind that profiled/tagged sRGB and
un-profiled/un-tagged RGB images will display differently in color
managed browsers/environments. The assumption that Gimp currently makes
(for historical reasons, explained by Sven previously) about 'assigning
sRGB color profile' being the same as 'having no color profile' is
misleading.

-Jason Simanek

On 03/10/2010 09:40 AM, Jason Simanek wrote:
> On 03/10/2010 02:37 AM, Sven Neumann wrote:
>> Some file formats, such as PNG for example, allow to tag the file to be
>> in a particular well-known color space. The color profile is not
>> embedded then, it is assumed to be well-defined. Instead of distributing
>> the profile with the image file, there is just a flag saying "this data
>> should be interpreted as sRGB".
>
> Ah, so the color problems I am having with images created by Gimp are
> due to the PNG files being 'tagged' as sRGB. The color profile isn't
> embedded to the image, it's just specified and, since it's a well known
> color profile, any program that attempts to display the image will do so
> as though the PNG had an embedded sRGB profile. Thanks for pointing that
> out.
>
> To summarize:
> Tagging is great because it specifies a color profile without increasing
> the image file size. Assuming that the destination system applies the
> correct profile.
>
> Embedding is great because you have greater flexibility for an endless
> variety of custom color profiles.
>
> The end result of the two is the same though: the image will be color
> managed.
>
> ----------------------
>
> As for gballard's recommendation for not including color profiles in web
> images: He's only saying that because his ultimate goal is color
> consistency across all platforms/browsers.
>
> I, as a professional web designer, think he's right when it comes to
> page element images that are intended to match colors defined in HTML or
> CSS. Otherwise all of the Safari users that visit your site are going to
> doubt your design capabilities. For photographs I think it's fine to
> include color profiles. Browsers that don't color manage are going to
> show you the same limited gamut either way, but browsers that DO color
> manage will display an enhanced image with a wider gamut of colors.
> Progressive enhancement.
>
> You do have to also keep in mind that profiled/tagged sRGB and
> un-profiled/un-tagged RGB images will display differently in color
> managed browsers/environments. The assumption that Gimp currently makes
> (for historical reasons, explained by Sven previously) about 'assigning
> sRGB color profile' being the same as 'having no color profile' is
> misleading.
>
> -Jason Simanek

Jason,

You are going to hate this suggestion, but as long as certain browsers
are causing you a problem, you may have to do "browser sniffing" and
serve those users different content. In other words, different image
files get called for different browsers. Of course, everything about
that is "wrong", but it solves your problem.

Jay

On Wed, Mar 10, 2010 at 6:04 PM, Jay Smith <jay@jaysmith.com> wrote:
> You are going to hate this suggestion, but as long as certain browsers
> are causing you a problem, you may have to do "browser sniffing" and
> serve those users different content.  In other words, different image
> files get called for different browsers.  Of course, everything about
> that is "wrong", but it solves your problem.

Problem is not serving different content. Problem is making content
that works for those, and ultimately for all browsers. So your
suggestion misses the point. The point is need to create images that
are not color managed or rather are managed as browser sees fit.

On Wed, Mar 10, 2010 at 11:31 AM, Alexia Death <alexiadeath@gmail.com> wrote:
> Problem is not serving different content. Problem is making content
> that works for those, and ultimately for all browsers. So your
> suggestion misses the point. The point is need to create images that
> are not color managed or rather are managed as browser sees fit.

Right. I don't think client sniffing is very efficient and probably
more complicated than needed. The 'progressive enhancement' approach
is much more pragmatic and one that is employed with other web
development features like CSS and JavaScript.

There are times when you have to work with the lowest common
denominator (web page image elements that need to match HTML and CSS
colors) and others where progressive enhancement allows you to provide
additional features/functionality without negatively affecting
visitors that aren't using the latest browsers (photographs with color
profiles).

-Jason Simanek