Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On Tue, Nov 18, 2014 at 7:00 PM, Elle Stone wrote: > Michael Henning did understand and did make appropriate changes to babl's > hard-coded sRGB Y values. But I doubt whether any of the other devs > understood; if they did, babl wouldn't still use D65 device sRGB to convert > to XYZ before converting to LAB, and GIMP wouldn't still be full of > hard-coded D65 device sRGB Y values. See: Elle, assuming that things are not done/fixed, because we don't understand them or don't care about them, is simply incorrect. We have a roadmapful of things we care about which still need someone to work on. It really is that easy. By now, it's been repeated about a dozen of times that we had adjusted our plans in the past to honor your useful input, and we are going to do so in the future __time permitting__. Is there a good reason why there should be another dozen of times for this to be said in the public? As Michael already stated, there are things we simply don't know yet, because they are implementation details. hence we don't have all the answers for you. Please show us some patience. Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
As a small aside... Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote: > We'd like to keep the interaction professional, thank you. I'd like to ask everyone involved in this discussion to remove the gimp-user mailinglist from the CC-list. The level of this discussion really is hardcore gimp-devel stuff and there is no need to duplicate it on gimp-user. People on gimp-user who are interested in this discussion are welcome to join gimp-devel. Let this be the last mail in this thread duplicated to both of the lists :) Thanks, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On 11/18/2014 11:00 AM, Elle Stone wrote: Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y: * https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages * http://ninedegreesbelow.com/photography/srgb-luminance.html. Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See: Sorry, typo, the "See:" is misplaced. It should read: Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y See: * https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages * http://ninedegreesbelow.com/photography/srgb-luminance.html. Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On 11/18/2014 03:05 AM, Michael Henning wrote: On Mon, Nov 17, 2014 at 11:39 PM, Gez wrote: P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive? Yes, I think that discussing this is counterproductive because it is premature. If I had spent the time I spent responding to color-related emails on coding this system instead, it would easily be working right now. If I had not spent time and effort explaining the problems *before* you got around to implementing unbounded sRGB image editing, you would have coded up a "working" high bit depth GIMP that was steadily churning out wrong results. And I'd be filing a whole lot of bug reports. Then, we could be discussing the details of a system that actually existed, instead of the details of a system that does not exist, and if current rates of coding continue, will never exist. And the discussion would be exactly the same. You would still need to use UserRGB chromaticities instead of sRGB chromaticities. But you'd have to undo a lot of new code to get there. Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y: * https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages * http://ninedegreesbelow.com/photography/srgb-luminance.html. Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See: GIMP really does need someone on the team who understands ICC profile color management. But it doesn't do any good to have such a person around unless you actually listen. To listen *intelligently* so you can ask the right questions when your color management person seems to be giving wrong advice (I'm just as capable as the next person when it comes to giving wrong advice), you need to understand a little bit about ICC profile color management. I've done my best to make this task easier: Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs http://ninedegreesbelow.com/photography/xyz-rgb.html I've learned a lot while trying to explain where babl/GEGL/GIMP has gone off track regarding one or another color management issue. Hopefully the exchange of knowledge has been a two-way street. You say I should stop responding, but it's hard to stop responding when novels are being written about how wrong you are, but you believe you are right. It's hard to stop responding when an article portraying you as incompetent appears on hacker news. It's hard to stop responding when you genuinely want people to understand. -- drawoc I agree with you that it's hard to stop responding when you want people to understand something that you care about. I doubt whether any of you have a clue just how much I value GIMP as an RGB image editor. But GIMP is critically important to free/libre artists and therefore GIMP color management needs to be right. Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it*by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it? This is exactly the right question. It will me take a bit of time to put together a straight answer that is also not one of my "walls of words". I'll try to post the answer today or at least by tomorrow morning. Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On Tue, Nov 18, 2014 at 6:27 PM, Ed . wrote: > Great! Glad to hear it! > > Please prove to us If you have personal issues with any of the list members, I strongly advice taking it off-list. We'd like to keep the interaction professional, thank you. Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
These are the type of emails that are not helpful. It is not helpful also because it's a rephrased email that was sent 15 hours ago. Simos On Tue, Nov 18, 2014 at 5:27 PM, Ed . wrote: > Great! Glad to hear it! > > Please prove to us your understanding by expressing, in your own words, > the difference between a design detail and an implementation detail. > > Ciao, > Ed > > -Original Message- From: Elle Stone > Sent: Tuesday, November 18, 2014 10:17 AM > To: Ed . ; Mikael Magnusson > Cc: gimp-user-list@gnome.org ; gimp-developer-l...@gnome.org > Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL > > On 11/17/2014 07:32 PM, Ed . wrote: > >> Elle, >> >> If you don't understand the difference between a design detail, and an >> implementation detail, you need to either a) go away and get to >> understand that difference; or b) stop commenting. I am neutral as to >> which you choose. >> >> Ed >> > > Again, Ed, in this discussion you don't have a leg to stand on. > > ___ > gimp-developer-list mailing list > List address:gimp-developer-l...@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp- > developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On 11/17/2014 07:32 PM, Ed . wrote: Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed Again, Ed, in this discussion you don't have a leg to stand on. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On 11/17/2014 06:56 PM, Simon Budig wrote: Oh, I was under the assumption that AdobeRGB had well defined chromaticies. If that is not the case then please consider my example moot. I am well aware that dealing with color profiles most definitely is not my area of expertise. It absolutely does have well-defined chromaticities. LCMS specifies an odd value for D65 and doesn't compensate for hexadecimal rounding. And so almost everyone who distributes ICC profiles made with LCMS makes AdobeRGB1998-compatible profiles that don't exactly match the Adobe specifications. Graham Gill distributes ClayRGB1998.icm that exactly matches the Adobe specs. I've submitted code to GIMP to make a proper AdobeRGB1998-compatible profile. Other free/libre profile makers really aren't distributing an exact match to the Adobe specs. I've already reported this on the LCMS mailing list. Similar problems obtain with a lot of other free/libre ICC profiles. Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed -Original Message- From: Elle Stone Sent: Monday, November 17, 2014 11:52 PM To: Mikael Magnusson Cc: gimp-user-list@gnome.org ; gimp-developer-l...@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL On 11/17/2014 05:41 PM, Mikael Magnusson wrote: On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone wrote: On 11/17/2014 10:46 AM, Simon Budig wrote: I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. The above two things are implementation details as Simon said. There is no reason to *store* the image using the sRGB chromaticities unless you also intend to *edit* the image using the sRGB chromaticities, or else if you intend to convert the image to unbounded sRGB and then to Y or else to XYZ and then maybe to CIELAB. So yes, the question of how you *store* the user's RGB data really does matter. It's not just an implementation detail. Unless maybe you think it's reasonable to randomly re-encode the user's RGB data using the sRGB chromaticities "just because you can". If you don't understand this, then please don't write long articles full of misinformation that get widely quoted.Your answers suggest you didn't even understand what he said. I do understand what Simon said. And I'm waiting for Pippin to clarify whether *Pippin* intends that images will be converted to unbounded sRGB before performing chromaticity independent RGB editing operations. If Pippin's answer is "yes, the image will be converted to unbounded sRGB for chromaticity independent RGB editing operations", I want to ask him why. There are many bad consequences of doing this. So if Pippin's answer is "yes", there must be some advantages that I don't see. Pippin and Jon Nordby seem to be saying different things. Three times Nordby has said that the image won't be converted to sRGB except for the handful of editing operations that really can't be generalized. (As an aside, in these cases, I hope a UI warning will be provided so the user knows what's going on and can exercise the right to not use the affected operation.) And three times Pippin has made statements that seem to directly contradict Jon Nordby. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Umm, could you untangle your analogy? Because all of sudden the integer encodings became undisplayable images. I assure you that if you add integers encoded using binary, while thinking you are adding decimal numbers, you will almost certainly get results that diverge from what you expect, adding 0+1 being an obvious exception. And if you composite colors thinking you are compositing in UserRGB, when really you are compositing in sRGB, likewise you are very likely to get results other than what you expected. Gegl stores pixels in memory in some format, it knows what format it used. babl and GEGL do communicate with each other as to what format the data is in and what format is needed next. Are you trying to say something else? Gimp can display/edit pixels in some color space (specified by the user). Well, this really is the question: according to Pippin, what color space chromaticities will be used for chromaticity independent RGB editing operations? UserRGB's or sRGB's? Gimp asks Gegl for pixels saying what colorspace it wants. Well, sometimes GIMP specifies the babl format and sometimes GEGL specifies the babl format. The question is whether for RGB editing operations the format so specified will ever be unbounded sRGB. Each time Nordby seems to say no, Pippin seems to say yes. Gegl presents the pixels to Gimp.All is well. It doesn't matter how the pixels are stored. Again, there is no reason to re-encode and *store* the pixels using the sRGB chromaticities *unless* there is an intention to *use* the re-encoded information for some purpose other than storing the pixels. As GIMP is an image editor, presumably that purpose would be for *editing*, and the format the pixels are in for editing does matter a great deal. Elle ___ gimp-developer-list mailing list List address:gimp-developer-l...@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On Mon, Nov 17, 2014 at 11:56 PM, Simon Budig wrote: > If there were chromaticies for a given "userRGB" which are widely used > in a lot of real world applications, then it might make sense to support > them in a similiar way like we currently do for the sRGB primaries. Nah, we only need one unbounded PCS ;) – other linear RGB spaces, like linear adobeRGB, are a matrix transform away from linear bablRGB. There might however be some non-similar ways to optimize things, however many of those likely add decision overhead in scenarios like per scanline calls for partial tile conversions that cancel out the benefit over just doing a straight matrix transform. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
Elle Stone (ellest...@ninedegreesbelow.com) wrote: > >A slight preface here. I don't consider it important to focus on the > >*storage* of the pixel data, as in the actual bulk memory for the pixel > >data. > > If you choose to *store* the user's RGB data using chromaticities not of > user's choosing, that suggests that you also intend to *edit* the user's RGB > data using chromaticities not of user's choosing I think that this is the core of the misunderstanding here. In Gegl the *storage* of pixel data in memory is totally and 100% independent from the colorspace used to *edit* the user's RGB data. You seem to think that the storage "suggests" an intent, but a lot of the communication from pippin, jonnor and me is about explaining that this is *not* the case. Obviously it makes a lot of sense to bring storage and editing workspace in line to avoid computational bottlenecks. But this is just a performance optimization, i.e. implementation detail. > >>1. Upon opening an image, the image will be converted to unbounded sRGB. > > > >I don't think that this is decided yet, I actually consider it unlikely > >at the moment. I think it might be more likely to have it sitting in > >memory as userRGB.But again, this is an implementation detail, where I > >assume that the floating point math is sufficiently precise to avoid > >visible rounding errors. > > This is not just an implementation detail. The user has the right to control > what RGB working space is used when performing RGB edits on the user's own > RGB data. We need to make sure two things: a) upon import of an image the "userRGB"-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image. b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the "userRGB" format from the images context. Note that this is totally independent from the pixel *storage* in memory. This will work the same when the pixel *storage* is in userRGB, sRGB or XYZ. > >For all chromaticity dependent RGB editing operations the pixels will be > >re-encoded in the format the operations requests. Which most likely will > >be userRGB. > > If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user > really does expect that *all* RGB edits wil be done using the user's chosen > RGB working space chromaticities. We agree here. The *edits* for the chromaticity dependent operations need to be done in the chromaticies of the source image. > >If specific userRGB to XYZ/whatever transforms are > >available to babl it will make use of them. This will likely be the case > >for e.g. AdobeRGB. > > OK, if I understand what you just said, this is getting silly. > > I think you are indicating a willingness to write hard-coded AdobeRGB > editing operations and put them right alongside the hard-coded sRGB editing > operations. Oh, I was under the assumption that AdobeRGB had well defined chromaticies. If that is not the case then please consider my example moot. I am well aware that dealing with color profiles most definitely is not my area of expertise. If there were chromaticies for a given "userRGB" which are widely used in a lot of real world applications, then it might make sense to support them in a similiar way like we currently do for the sRGB primaries. If that is not the case then this indeed would be silly. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On 11/17/2014 05:41 PM, Mikael Magnusson wrote: On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone wrote: On 11/17/2014 10:46 AM, Simon Budig wrote: I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. The above two things are implementation details as Simon said. There is no reason to *store* the image using the sRGB chromaticities unless you also intend to *edit* the image using the sRGB chromaticities, or else if you intend to convert the image to unbounded sRGB and then to Y or else to XYZ and then maybe to CIELAB. So yes, the question of how you *store* the user's RGB data really does matter. It's not just an implementation detail. Unless maybe you think it's reasonable to randomly re-encode the user's RGB data using the sRGB chromaticities "just because you can". If you don't understand this, then please don't write long articles full of misinformation that get widely quoted.Your answers suggest you didn't even understand what he said. I do understand what Simon said. And I'm waiting for Pippin to clarify whether *Pippin* intends that images will be converted to unbounded sRGB before performing chromaticity independent RGB editing operations. If Pippin's answer is "yes, the image will be converted to unbounded sRGB for chromaticity independent RGB editing operations", I want to ask him why. There are many bad consequences of doing this. So if Pippin's answer is "yes", there must be some advantages that I don't see. Pippin and Jon Nordby seem to be saying different things. Three times Nordby has said that the image won't be converted to sRGB except for the handful of editing operations that really can't be generalized. (As an aside, in these cases, I hope a UI warning will be provided so the user knows what's going on and can exercise the right to not use the affected operation.) And three times Pippin has made statements that seem to directly contradict Jon Nordby. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Umm, could you untangle your analogy? Because all of sudden the integer encodings became undisplayable images. I assure you that if you add integers encoded using binary, while thinking you are adding decimal numbers, you will almost certainly get results that diverge from what you expect, adding 0+1 being an obvious exception. And if you composite colors thinking you are compositing in UserRGB, when really you are compositing in sRGB, likewise you are very likely to get results other than what you expected. Gegl stores pixels in memory in some format, it knows what format it used. babl and GEGL do communicate with each other as to what format the data is in and what format is needed next. Are you trying to say something else? Gimp can display/edit pixels in some color space (specified by the user). Well, this really is the question: according to Pippin, what color space chromaticities will be used for chromaticity independent RGB editing operations? UserRGB's or sRGB's? Gimp asks Gegl for pixels saying what colorspace it wants. Well, sometimes GIMP specifies the babl format and sometimes GEGL specifies the babl format. The question is whether for RGB editing operations the format so specified will ever be unbounded sRGB. Each time Nordby seems to say no, Pippin seems to say yes. Gegl presents the pixels to Gimp.All is well. It doesn't matter how the pixels are stored. Again, there is no reason to re-encode and *store* the pixels using the sRGB chromaticities *unless* there is an intention to *use* the re-encoded information for some purpose other than storing the pixels. As GIMP is an image editor, presumably that purpose would be for *editing*, and the format the pixels are in for editing does matter a great deal. Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On 11/17/2014 10:46 AM, Simon Budig wrote: Hi Elle. The following is my understanding, when pippin answers his answers have more authority than mine. Hi Simon, I appreciate your answers, but the points you make aren't actually relevant to the questions that I wanted to ask Pippin. This is my fault. In an effort to clarify what I think he's saying, I seem to have just opened the door for more miscommunication. Elle Stone (ellest...@ninedegreesbelow.com) wrote: Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. 2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed. Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest. This really is an implemetation detail. For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user really does expect that *all* RGB edits wil be done using the user's chosen RGB working space chromaticities. 3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing. For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ. This brings me to the question that I was planning on asking Pippin. If Pippin *doesn't* intend to convert the image to unbounded sRGB before performing any RGB editing operations, then my question is irrelevant. So the "pre question" is: Does Pippin intend that the image will be converted to unbounded sRGB before performing chromaticity *in*dependent RGB editing operations? If Pippin's answer to the "pre question" is yes, here's the question I wanted to ask Pippin: 1. We've agree that many RGB editing operations really are chromaticity dependent and therefore should be done using the user's chosen RGB working space chromaticities. 2. We've agree that for chromaticity *in*dependent editing operations, the resulting colors as located in the XYZ reference color space are the same *regardless* of the chromaticities used to encode the RGB data before performing the operation. Given the above two points of agreement, what is point of EVER converting the image to unbounded sRGB? I can list a whole bunch of disadvantages. But I don't understand what the advantages are supposed to be. I thought Jon Nordby had made it clear (more than once) that for all RGB editing operations, the user's chosen RGB working space's chromaticties would be used. But it's hard to tell whether Pippin agrees with Jon Nordby. So I'm asking Pippin as directly as possible whether he ever intends that RGB editing will be done using sRGB chromaticities instead of the user's chosen RGB working space's chromaticities. If Pippin's answer is "yes", then the next question is "Why?". (Sorry for repeating, but this is an important point: in a given image context "userRGB" really is not conceptually different from sRGB or XYZ, My apologies, but this statement makes no sense unless you mean the trivially obvious point that RGB color data can be losslessly converted to various unbounded color spaces including the XYZ reference color space, of course putting aside floating point precision limitations and sundry other sources of computational loss of precision. it gets slightly more complicated when two images with different user chromaticies are to be combined.) Again, let the *user* decide what RGB working space to use for combining images. Except for the few compositing operations that ar
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
Hi Elle. The following is my understanding, when pippin answers his answers have more authority than mine. Elle Stone (ellest...@ninedegreesbelow.com) wrote: > Putting aside coding considerations that might affect other software that > uses babl and GEGL, here's my understanding of your current plan for > babl/GEGL/GIMP: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. The important part is, that the data is available to the operations in the format they request upon request. If that is in memory already pre-converted or if that gets converted on the fly is an implementation detail. > 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB. But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. > 2. For all chromaticity dependent RGB editing operations: >* Either the image will be re-encoded using the user's chosen RGB working > space chromaticities, and then the operation will be performed. >* Or else the image will be converted to CIELAB and then the operation > will be performed. Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest. For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format. > 3. For all chromaticity *in*dependent RGB editing operations, the image will > be converted to unbounded sRGB for processing. For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format. (Sorry for repeating, but this is an important point: in a given image context "userRGB" really is not conceptually different from sRGB or XYZ, it gets slightly more complicated when two images with different user chromaticies are to be combined.) > 4. When converting to XYZ/CIELAB/etc, the image will first be converted to > unbounded sRGB. Not necessarily. If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB. > 5. The GEGL developers will specify on an "operation by operation" basis > whether the operation requires being encoded using UserRGB/Y/etc, or > unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent > RGB processing, or etc. It probably will be specified within the implementation. I.e. there won't be a pre-existing separate document with a list for each individual operation. However there might be such a document generated from the implementation. > As an important note, depending on the last operation that was done, the > image might already be encoded using the GEGL-operation-specified format, in > which case a conversion to that format is not needed. Yes, but it is important to keep in mind that we don't sequentially apply one operation after each other, with image-in-memory-steps inbetween. We build a graph of connected operations, where the connections between the nodes will be negotiating the resp. pixel formats. *Then* the pixel data will be fed from the sources into the graph, flow through the graph, have the operations operate on them, potentially converting them to the negotiated pixel formats and finally get sunk into the output (e.g. the node painting into the image view). Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
