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?
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?
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 ___ 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] Adding ability to reverse curves dialog
On 03/09/2010 09:06 PM, David Gowers wrote: > On Wed, Mar 10, 2010 at 8:19 AM, Jay Smith wrote: >> On 03/09/2010 04:39 PM, Jon Senior wrote: >>> On Tue, 09 Mar 2010 16:30:58 -0500 >>> Jay Smith wrote: >>> I am not sure where the "standard" that you mention comes from. I had never seen black at bottom left (by default) until I started to use Gimp. Is there some actual scientific standard underlying that? Or just majority of programs? Or the programs you have used? Or? Maybe the programs I have used in the past were backward. >>> I would suggest that they were. The "curves" are graphs plotting value >>> in (x) against value out(y). Traditionally a graph starting at 0 for >>> both axes would be drawn with the origin in the bottom-left. >>> >>> This naturally leads to a curves graph where black (0) is in the >>> bottom-left and white (255/1023/...) is in the top-right. >>> >>> What programs have you used where this situation was reversed? >>> >>> Jon >> Jon, >> >> That is certainly possible. >> >> The one that most comes to mind is Photoshop 5.x. >> >> I have no idea what "modern" Photoshop and successors do. >> > http://www.adobe.com/designcenter/photoshop/articles/phscs2at_learncurves_02.html > > White on the right, Same as GIMP, PSP, etc. Thanks David, Yep, that's what that picture shows. BUT... that little double-arrow thingy at the bottom of the curves graph reverses black/white positions. It is entirely possible that umpteen years ago when we first installed Photoshop on Windows 95 that that double arrow got clicked and we have used it reversed ever since. Or maybe back then white was at the upper right. Okay, if the world says black is lower left, we will use it that way. Thanks. Case closed. Jay ___ 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 Wed, Mar 10, 2010 at 8:19 AM, Jay Smith wrote: > On 03/09/2010 04:39 PM, Jon Senior wrote: >> On Tue, 09 Mar 2010 16:30:58 -0500 >> Jay Smith wrote: >> >>> I am not sure where the "standard" that you mention comes from. I had >>> never seen black at bottom left (by default) until I started to use >>> Gimp. >>> >>> Is there some actual scientific standard underlying that? Or just >>> majority of programs? Or the programs you have used? Or? >>> >>> Maybe the programs I have used in the past were backward. >> >> I would suggest that they were. The "curves" are graphs plotting value >> in (x) against value out(y). Traditionally a graph starting at 0 for >> both axes would be drawn with the origin in the bottom-left. >> >> This naturally leads to a curves graph where black (0) is in the >> bottom-left and white (255/1023/...) is in the top-right. >> >> What programs have you used where this situation was reversed? >> >> Jon > > Jon, > > That is certainly possible. > > The one that most comes to mind is Photoshop 5.x. > > I have no idea what "modern" Photoshop and successors do. > http://www.adobe.com/designcenter/photoshop/articles/phscs2at_learncurves_02.html White on the right, Same as GIMP, PSP, etc. ___ 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/8 Aurimas Juška : > Hi, > > On Sun, Mar 7, 2010 at 5:50 PM, Alexia Death wrote: >>> By the way, is there somewhere some explanations about the purpose and use >>> of tags and filters? I think I can guess a large part of this, but reading >>> authorized text would be useful. >> >> I doubt there is a text, even less authorized one, on this. Closest you can >> get is when you find Auris , the author of this feature, in IRC and get him >> to >> talk to you. Shouldn't be that complicated tho. you can assign tags to >> resources and you can use filters to see just the tagged ones. > > You can go to http://sites.google.com/site/aurijusk/gimp-resource-tagging > and choose tagging.pdf. > > Regards, > Aurimas Hi- In that document it states: Easy resource package import and export It would be nice to allow users to share their favorite resources which could be saved into packages (together with tags assigned to them) and then shared with other users which could import them. 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? -Rob A> ___ 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 03/09/2010 04:39 PM, Jon Senior wrote: > On Tue, 09 Mar 2010 16:30:58 -0500 > Jay Smith wrote: > >> I am not sure where the "standard" that you mention comes from. I had >> never seen black at bottom left (by default) until I started to use >> Gimp. >> >> Is there some actual scientific standard underlying that? Or just >> majority of programs? Or the programs you have used? Or? >> >> Maybe the programs I have used in the past were backward. > > I would suggest that they were. The "curves" are graphs plotting value > in (x) against value out(y). Traditionally a graph starting at 0 for > both axes would be drawn with the origin in the bottom-left. > > This naturally leads to a curves graph where black (0) is in the > bottom-left and white (255/1023/...) is in the top-right. > > What programs have you used where this situation was reversed? > > Jon Jon, That is certainly possible. The one that most comes to mind is Photoshop 5.x. I have no idea what "modern" Photoshop and successors do. Jay ___ 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 03/09/2010 04:12 PM, Sven Neumann wrote: > Hi, > > On Tue, 2010-03-09 at 15:51 -0500, Jay Smith wrote: > >> The above exchange occurred today on the Gimp-User list. >> >> I am posting here for discussion prior to posting an Enhancement >> Suggestion on Bugzilla. >> >> For a future version, I wish to propose adding the ability to reverse >> the direction of the black/white in the Curves dialog. A toggle button. > > The reason that I suggested that you do this change to your local copy > of GIMP is that I don't think that this change would be useful for a > large part of our target user base. > > Adding this option to the source code will make the code harder to > maintain and will increase the likelihood of bugs being introduced (by > that particular change or at a later point in time). Adding a toggle > button will make the user interface more complex and will degrade the > user experience for most users. > > So unless you can persuade us that this feature is in-line with the > product vision that we have for GIMP and that it is indeed important > enough to outweigh the disadvantages that I explained above, we are not > going to consider it. > > > Sven The greatest benefit that comes to my mind is that it puts the user in control and allows the user to align the program to their way of thinking/working. However, *if* Alexia is correct and that the "standard" is to do it as Gimp currently does (black in lower left), then making such a change is not as useful to most users as it would be to me. While "putting the user in control" may or may not (?) be part of Gimp's product vision, I suggest that it should be. The same can be said for things like having the program remember various dialog settings the user has changed. (I posted about one of those in the Gimp-User list today.) 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. Jay ___ 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 Tue, 09 Mar 2010 16:30:58 -0500 Jay Smith wrote: > I am not sure where the "standard" that you mention comes from. I had > never seen black at bottom left (by default) until I started to use > Gimp. > > Is there some actual scientific standard underlying that? Or just > majority of programs? Or the programs you have used? Or? > > Maybe the programs I have used in the past were backward. I would suggest that they were. The "curves" are graphs plotting value in (x) against value out(y). Traditionally a graph starting at 0 for both axes would be drawn with the origin in the bottom-left. This naturally leads to a curves graph where black (0) is in the bottom-left and white (255/1023/...) is in the top-right. What programs have you used where this situation was reversed? Jon ___ 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 Tue, Mar 9, 2010 at 11:30 PM, Jay Smith wrote: > On 03/09/2010 04:12 PM, Alexia Death wrote: > Is there some actual scientific standard underlying that? Or just > majority of programs? Or the programs you have used? Or? That standard is based on the fact that Ive never seen a curves tool that is not like that. This and the fact that this the sane direction of any value axis covering positive values. -- --Alexia ___ 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 03/09/2010 04:12 PM, Alexia Death wrote: > On Tue, Mar 9, 2010 at 10:51 PM, Jay Smith wrote: >> Does anybody other than me think that it would be a useful feature to >> add the ability to reverse the Curves black/white direction? > I find it about a useless as a feature as it gets. Standard curve > direction is black bottom left and white top right. If there is a > problem about understanding the curve, that might be made more clear, > but not by switching directions. > > Just my personal opinion here tho. Hi Alexia, I am not sure where the "standard" that you mention comes from. I had never seen black at bottom left (by default) until I started to use Gimp. Is there some actual scientific standard underlying that? Or just majority of programs? Or the programs you have used? Or? Maybe the programs I have used in the past were backward. Jay ___ 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 Tue, Mar 9, 2010 at 10:51 PM, Jay Smith wrote: > Does anybody other than me think that it would be a useful feature to > add the ability to reverse the Curves black/white direction? I find it about a useless as a feature as it gets. Standard curve direction is black bottom left and white top right. If there is a problem about understanding the curve, that might be made more clear, but not by switching directions. Just my personal opinion here tho. -- --Alexia ___ 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 15:51 -0500, Jay Smith wrote: > The above exchange occurred today on the Gimp-User list. > > I am posting here for discussion prior to posting an Enhancement > Suggestion on Bugzilla. > > For a future version, I wish to propose adding the ability to reverse > the direction of the black/white in the Curves dialog. A toggle button. The reason that I suggested that you do this change to your local copy of GIMP is that I don't think that this change would be useful for a large part of our target user base. Adding this option to the source code will make the code harder to maintain and will increase the likelihood of bugs being introduced (by that particular change or at a later point in time). Adding a toggle button will make the user interface more complex and will degrade the user experience for most users. So unless you can persuade us that this feature is in-line with the product vision that we have for GIMP and that it is indeed important enough to outweigh the disadvantages that I explained above, we are not going to consider it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Adding ability to reverse curves dialog
On the GIMP-USER list On 03/09/2010 03:02 PM, Brendan wrote: > On Tuesday 09 March 2010, Sven Neumann wrote: >> On Tue, 2010-03-09 at 14:49 -0500, Jay Smith wrote: >>> The Color > Curves dialog has the black in the lower left corner >>> and the white in the upper right corner. This is the opposite of >>> another program that I also have to use. Is there a way to >>> reverse this default? >> >> GIMP is Free Software. You are given the source code and the right >> to modify it according to your needs. > > Oh, Sven, how users love your answers. > > To the OP: no, there is no option to switch it. You would have to > change the source code and recompile. The above exchange occurred today on the Gimp-User list. I am posting here for discussion prior to posting an Enhancement Suggestion on Bugzilla. For a future version, I wish to propose adding the ability to reverse the direction of the black/white in the Curves dialog. A toggle button. Given that Gimp has such a great feature for storing past Curves adjustments, I am concerned that the toggle state would need to be added to that information storage. Does anybody other than me think that it would be a useful feature to add the ability to reverse the Curves black/white direction? Thanks. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image sharpening with "compressed sensing"
You might wish to read the clarification at http://nuit-blanche.blogspot.com/2010/03/why-compressed-sensing-is-not-csi.html It explains how that Wired article is misleading, and why the technique is probably not very useful for the sorts of situations that Gimp users commonly encounter. Regards, -- Bill Skaggs ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Image sharpening with "compressed sensing"
Hi, I'll start by saying I am neither a GIMP developer nor do I have any experience with algorithmic image manipulation. However, as a GIMP user I *REALLY* wanted to make sure the GIMP development community is aware of the following since many of you *DO* have the talent needed to handle this. It seems there is a new mathematical technique available which can be used to sharpen blurry or noisy images. From what I have just read it produces near magical results. To quote from the article regarding the improvement in the images: "It was as if you gave me the first three digits of a 10-digit bank account number — and then I was able to guess the next seven." I am also not a mathematician, but I can sort of understand how the algorithm works: It modifies the images repeatedly and on finer and finer scales converging always towards lower image complexity thus eliminating much blurriness and noise. In point of fact almost all real-life subjects have edges and other structures. The real world is mostly not blurred. This "compressed sensing" algorithm somehow implicitly "understands" (note the quotes) that blur and noise is not what the real world is about and it is able to supply missing data to correct images from the real world. Here is a pointer to a recent article on the subject published in Wired Magazine. Please read it. http://www.wired.com/magazine/2010/02/ff_algorithm/all/1 As GIMP user who looses a lot of images due to them being underexposed or out of focus, I'd *REALLY* love to see a "compressed sensing" image sharpener plugin for GIMP. I think many other GIMP users would like it a lot too. Thanks for reading, Jeff Barry Acton, MA, USA. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
