Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On Wed, Mar 10, 2010 at 6:04 PM, Jay Smith j...@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. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On Wed, Mar 10, 2010 at 11:31 AM, Alexia Death alexiade...@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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
Hi, On Mon, 2010-03-08 at 05:53 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
Hi, On Fri, 2010-03-05 at 07:34 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On Thu, 2010-03-04 at 19:49 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On 03/04/2010 09:01 PM, Sven Neumann wrote: On Thu, 2010-03-04 at 19:49 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
