Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
On 2/10/10, yahvuu wrote: > Among garden-variety photo labs, it's pretty much standard to discard any > color profile information and just assume sRGB. It's pretty much standard where you live maybe, but not where *I* live :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
Martin Nordholts wrote: > "4) When an image with an explicit profile is exported >c) If the file format has no way to embed color profile information, > (FIXME!)" > > In terms of a problem, this is pretty similar to "when an image has > several layers and we export to an image format that does not support > layers, what do we do?". If the image doesn't support any kind of layer, > we simply merge or flatten the image, no questions asked. If the image > supports both layers and non-layers (such as animated GIF), we let the > user choose. I think we should do the same in this case: if the target > image format does not support color management whatsoever, we should > just write the RGB values verbatim, i.e. do the best of the situation > without becoming annoying and asking questions. If the written RGB > values are important than the user needs to do a color space conversion > before exporting into that format. While this is certainly a good point and in contrast to what i've proposed elsewhere [1], i'm a lot less shure that this the best solution. The counter-arguments are just too striking: a) *Not* converting to sRGB by default fosters the accidental release of unmanaged non-sRGB files, i.e. files, which cannot be interpreted correctly without external information. b) A cycle of export and re-import should preserve as much of the image data as possible to comply with the principle of least surprise. From assuming sRGB on import follows conversion to sRGB on export here. c) The layers analogy applies, but can be used with a slight twist: File formats that don't support profiles can be regarded as formats which don't support other color spaces than sRGB. So export should silently auto-convert by default. regards, yahvuu [1] https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-February/024222.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] More on tagging
Hi- I found this old thread: http://lists.freedesktop.org/archives/create/2009-February/001578.html That talks about tagging. I've also looked at the source, and am not able to locate how the checksum is calculated. It does not appear to be a md5sum of the actual resource file. How is it calculated? -Rob A> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint Dynamics in git version
2010/3/10 Aurimas Juška > Hi, > > 2010/3/10 Rob Antonishen >> What is the format for this? If I wanted to distribute (for example) >> a set of pre-tagged patterns, could this be done currently in the dev >> build? > > There is no such feature yet. The idea is a simple archive of resouces > + tags + possibly some metadata. When resource package is dragged on > GIMP it would install where necessary. Some tool to create such > packages would be good too. However, first tag file format would have > to be standardized a bit so that resource packages could be used not > only in GIMP. > > Additional ideas are welcome. > > Regards, > Aurimas > Thanks for the response. So where/how are tags stored now? In a separate rc fil somewhere? -Rob A> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint Dynamics in git version
Hi, 2010/3/10 Rob Antonishen : > What is the format for this? If I wanted to distribute (for example) > a set of pre-tagged patterns, could this be done currently in the dev > build? There is no such feature yet. The idea is a simple archive of resouces + tags + possibly some metadata. When resource package is dragged on GIMP it would install where necessary. Some tool to create such packages would be good too. However, first tag file format would have to be standardized a bit so that resource packages could be used not only in GIMP. Additional ideas are welcome. Regards, Aurimas ___ 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 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 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 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] Adding ability to reverse curves dialog
2010/3/10 : > On 10 March 2010 08:04, Sven Neumann wrote: >> Sorry, but the fact that another program has a toggle button for this is >> not an argument for adding such a toggle button to GIMP. So is there any >> work-flow or use-case for which it would be beneficial to reverse the >> direction? > > How about editing in CMYK space, where higher numbers mean greater ink > density? Perhaps this is why Photoshop has this 'flip' feature. Good point, but in this case GIMP can do the necessary invert and flip for the user, no need for a toggle for that. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding ability to reverse curves dialog
On 10 March 2010 08:04, Sven Neumann wrote: >> BUT... that little double-arrow thingy at the bottom of the curves >> graph reverses black/white positions. > > Sorry, but the fact that another program has a toggle button for this is > not an argument for adding such a toggle button to GIMP. So is there any > work-flow or use-case for which it would be beneficial to reverse the > direction? How about editing in CMYK space, where higher numbers mean greater ink density? Perhaps this is why Photoshop has this 'flip' feature. Of course GIMP is luminance only for now (higher numbers mean more light, not more ink) but this could change in the next few versions. John ___ 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?
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] Adding ability to reverse curves dialog
Hi, On Tue, 2010-03-09 at 16:47 -0500, Jay Smith wrote: > The general arguments you raise such as "code harder to maintain" and > "interface more complex" are all perfectly legitimate and could be said > of virtually any program change. However, they are not a "shield" from > change. Rather, they are a "filter" which must be passed as part of a > cost/benefit analysis. Indeed, that is exactly what they are. And that's why you need to give us reasons other than "I would like that feature because it would be useful for me". Otherwise this change has nothing but costs and will be rejected. > BUT... that little double-arrow thingy at the bottom of the curves > graph reverses black/white positions. Sorry, but the fact that another program has a toggle button for this is not an argument for adding such a toggle button to GIMP. So is there any work-flow or use-case for which it would be beneficial to reverse the direction? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
