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

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

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

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 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 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

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

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.