Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB
El vie, 11-04-2014 a las 02:39 +0200, Przemyslaw Golab escribió: > Isn't that expected? You don't change color space, for it to have the same > results. > > You choose best color space for the job and use it from beginning to the > end, > or if you know what you are doing convert it in middle of work to do the > thing > you want to do. > If all color spaces look the same whats the point of using them. Hi Przemyslaw, Unless I got it absolutely wrong, the plan for GIMP 2.10 is to use forced unbounded colorspace conversions to sRGB for the internal pipeline (at least that's what I got from Drawoc's reply to Elle's previous post). So anytime you open a wide gamut image, it will be converted internally to sRGB for all the processing and compositing. Since the unbounded conversion is reversible (unlike the usual icc bounded transforms that are destructive), in theory you could go back to your wide-gamut colorspace with no loss of color latitude upon export (once you're done with processing). What Elle is describing here is a number of operations that don't seem to work with unbounded sRGB (where values can go negative or >1 to express out of gamut colors and keep the excess gamut from the source wide gamut profile). I've repeated Elle's tests and tried my own tests, and I can see that some operations do break. I'm really interested about this issue, because some basic and important math operations seem to have issues with those out-of-bounds values (like multiplication/division). Gez. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi, On Thu, Apr 10, 2014 at 4:06 PM, scl wrote: > Hi, > > it's interesting to see what interest such a post can trigger ;-) > To be honest, it wasn't me who started the discussion, I just forwarded > Ingo's call to the mailing list. > > 'GIMP is easily user-extendable, by ‘one-click’ installation of > plug-ins.' is a part of our product-vision and as far as I remember > there have already been many ideas on this topic, dating back to 2003. > > For both the registry and GIMP the situation changes: > Registry: from some or many users who know and use the registry to > potentially every user who can access it conveniently from GIMP. These > are millions. > GIMP: From a standalone application that uses mostly local data to > an application with tighter access to an online service. > > I think before we start losing ourselves prematurely in implementation > details like programming language and data formats we should clarify > the overall picture first: > - What are the concrete requirements: functional and nonfunctional > requirements, > - user interaction, > - overall technical architecture and integration into GIMP, > - reuse of existing solutions like package managers, > - who will also care in future for the registry and the plug-in manager? > - Integration into the Jenkins builds and manpower to handle this. > > Examples for functional requirements: > * installing only plug-ins or also other assets, > * curation/quality assurance of provided assets, > * metadata of the assets, > * search and filter functionality. > > Examples for nonfunctional requirements: > * performance: be fluent, also with a slow internet connection, > * security, protection against abuse, > * scalability (how many users will access the registry at one time or > at maximum), > * target platform, > * maintainability (even with our given low resources). > > Perhaps it would - depending on our resources - first be better to cut > down the registry to the necessary part we can handle, e.g. to remove > the functionality that causes spam and start with a little > thing in GIMP, like a clickable link to open the registry in a > browser and easy to find assets folders in the Preferences. All this topic is one I am myself very interested too, and I actually have been thinking about it for 6 months. If we had been a Gsoc mentor organization this year, I was even hoping we could find a student willing to kickstart such a plugin management infrastructure (this was in my personal list of gsoc ideas meant to be merged with the rest: http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas ). Now if someone wants to take care of this, I am all for not overworking myself. :-) Otherwise, I would likely tackle the issue properly in a several months. I am currently farming alpacas :P thus in the impossibility to focus on such an important problem, but in end of May I will be much more dedicated to GIMP again (though I have several GIMP-related priorities at this time, before even thinking about a plugin management system). Now before I become silent again, I will still raise what I believe are much important problems than any technical issues: security and responsibilities of the GIMP project. If that had been a gsoc project, I would have given most of the technicalities to the student and would have taken care of security personally. Basically having a website where anyone can upload anything and anyone else is fully responsible for checking oneself and installing manually is one thing. But providing a plugin management system, released together and integrated with GIMP, which would download and install on the user's behalf, and even auto-update plugins is a completely different matter. If not mistaken, there is no proper sandbox for GIMP plugins, so they are technically executables that GIMP runs and which can do many kinds of nasty stuff. We suddenly have a much more bigger responsibility: - We must not accept anything without at the very least a minimum of check. Ideally we would need security analysis programs to automatically review each and every code uploaded (calls to third party URIs, attempt to access networks, system calls which are likely not normal in a GIMP plugins, etc.), then technical-minded contributors to review codes of any suspicious plugin (being the case when the previous automatic review did pick up some strange patterns) for any funny story (scam, attacks, using your computer as a ghost machine, etc.). We could of course start with a self-managed community (abuse button, vote system, etc.) until some admin steps in to install code review scripts, and enough users step in into code review duty. Many Free Software started their plugin management this way. Though obviously even with such a community system, I would feel fine only with at least a minimum of check. - We should definitely not accept uploaded binaries. For me, this is an absolute *no*. Binaries are black boxes. What it means is not that C plugins shou
Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB
Isn't that expected? You don't change color space, for it to have the same results. You choose best color space for the job and use it from beginning to the end, or if you know what you are doing convert it in middle of work to do the thing you want to do. If all color spaces look the same whats the point of using them. 2014-04-10 21:50 GMT+02:00 Elle Stone : > On 04/09/2014 06:36 PM, Elle Stone wrote: > >> For Lighten only, Darken only, Multiply, Divide, and some of the other >> blend modes, results are *highly dependent* on the color space in which >> the blending is done. Removing clipping code doesn't fix the problem. >> >> If the artist uses any of the color-space dependent blend modes: >> >> * Editing an image in a large gamut color space such as ProPhotoRGB >> produces one set of colors. >> >> * Converting the image to unbounded mode sRGB before editing it >> necessarily produces different colors - sometimes very different colors. >> >> For concrete examples showing how Lighten only and Darken only are >> color-space dependent, see >> http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html >> >> Can this problem be fixed? Is there a workaround such that an image can >> be converted from its source color space to unbounded mode sRGB, and >> then use the color-space dependent blend modes to produce the same >> colors that would have been produced if the image had been edited in the >> source color space instead of in unbounded mode sRGB? >> >> > I put up two more examples - not blend mode examples, rather channel > mixing and blending examples: > > > 1. Channel blending when converting to black and white > http://ninedegreesbelow.com/gimpgit/unbounded-srgb- > channel-blend-convert-black-white.html > > The example concludes: > > My envisioned conversion to black and white was simple to achieve in my > custom RGB working space: make a luminance-based conversion to black and > white, pull over the blue channel and set it to multiply blend mode, season > to taste. > > Converting the image to unbounded mode sRGB made my envisioned conversion > to black and white completely impossible. > > Worse, if I hadn't examined the blue channel data before the conversion to > the unbounded mode sRGB color space, I never would have seen the original > blue channel data. As the original blue channel contained all the > interesting information in this particular image, I would not have been > inspired to convert the image to black and white. No doubt no loss to art! > but that is not the point. The point is that a conversion to unbounded mode > sRGB radically rearranges channel data, which in turn radically alters the > information the artist has to work with. > > > 2. Using Channel Mixer to decrease saturation > http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-mixer-decrease- > saturation.html > > The example concludes: > > Channel data is radically rearranged when a saturated image is converted > from a wider gamut color space to the unbounded mode sRGB color space. A > consequence is that many crucially important editing tools no longer > function properly. Channel mixing is one such tool. > > In the custom RGB color space using Channel Mixer to desaturate the yellow > cone flower worked exactly as expected. > > In the unbounded mode sRGB color space using Channel Mixer to desaturate > the yellow cone flower failed completely. The flower wasn't actually > desaturated, and excessive amounts of the blue channel polluted the image's > original colors. > > > Thanks in advance for looking at the examples. > > Elle > > > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp- > developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB
On 04/09/2014 06:36 PM, Elle Stone wrote: For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem. If the artist uses any of the color-space dependent blend modes: * Editing an image in a large gamut color space such as ProPhotoRGB produces one set of colors. * Converting the image to unbounded mode sRGB before editing it necessarily produces different colors - sometimes very different colors. For concrete examples showing how Lighten only and Darken only are color-space dependent, see http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html Can this problem be fixed? Is there a workaround such that an image can be converted from its source color space to unbounded mode sRGB, and then use the color-space dependent blend modes to produce the same colors that would have been produced if the image had been edited in the source color space instead of in unbounded mode sRGB? I put up two more examples - not blend mode examples, rather channel mixing and blending examples: 1. Channel blending when converting to black and white http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-blend-convert-black-white.html The example concludes: My envisioned conversion to black and white was simple to achieve in my custom RGB working space: make a luminance-based conversion to black and white, pull over the blue channel and set it to multiply blend mode, season to taste. Converting the image to unbounded mode sRGB made my envisioned conversion to black and white completely impossible. Worse, if I hadn't examined the blue channel data before the conversion to the unbounded mode sRGB color space, I never would have seen the original blue channel data. As the original blue channel contained all the interesting information in this particular image, I would not have been inspired to convert the image to black and white. No doubt no loss to art! but that is not the point. The point is that a conversion to unbounded mode sRGB radically rearranges channel data, which in turn radically alters the information the artist has to work with. 2. Using Channel Mixer to decrease saturation http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-mixer-decrease-saturation.html The example concludes: Channel data is radically rearranged when a saturated image is converted from a wider gamut color space to the unbounded mode sRGB color space. A consequence is that many crucially important editing tools no longer function properly. Channel mixing is one such tool. In the custom RGB color space using Channel Mixer to desaturate the yellow cone flower worked exactly as expected. In the unbounded mode sRGB color space using Channel Mixer to desaturate the yellow cone flower failed completely. The flower wasn't actually desaturated, and excessive amounts of the blue channel polluted the image's original colors. Thanks in advance for looking at the examples. Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
