Re: [Gimp-user] I need the Gimp 2.9 where i can find ??
Von: Thorsten Stettin thorsten.stet...@gmail.com Hi Thorsten, you can use https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge sudo apt-get install gimp it would be nice if packages for the development branch would give users the ability to keep the current stable GIMP installed as well - being able to compare the behavior of the two is one of the points of installing a development version. If the 2.9.x package wouldn't be called gimp, but e.g. gimp-2.9 (or something similar, if this name doesn't correspond to Debian/Ubuntu package naming policies), this could be achievable. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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] Time to fork BABL and GEGL
On 11/16/2014 05:18 PM, Øyvind Kolås wrote: On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Do you understand that when I say that Multiply is a chromaticity-dependent editing operation, I don't just mean the Multiply layer blend mode? that in fact *all* editing operations that use multiplication or division are chromaticity dependent, regardless of whether the colors are *in* gamut or *out* of gamut with respect to the very small bounded sRGB color gamut? The exception to all, of course, is when multiplying or dividing by black, gray, or white. Yes I do understand that OK, thanks! for confirming. I was afraid my phrasing might have obscured an important point. 1. Do you agree or disagree that for *all* chromaticity dependentediting operations, the *user* should be in control of which RGBchromaticities are used to perform the operation? That is the point of adding more, and named, RGB families to babl. 2. Do you agree or disagree that for chromaticity *in*depedent editing operations (for example, and assuming linearized RGB: adding, scaling, gaussian blur, etc), the same results (same XYZ values) are obtained whether the operation is done in the user's chosen RGB working space or in unbounded sRGB? I do; So it appears that we agree on the following, yes? 1. The user's chosen RGB working space chromaticities should be used for performing all chromaticity dependent RGB editing operations. 2. For chromaticity independent RGB editing operations, the same XYZ values are obtained regardless of whether the operation is performed using the user's chosen RGB working space chromaticities or after converting the image to unbounded sRGB. Somewhat switching gears, the revised babl roadmap (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says: The plan in roadmap hasn't really changed since mid-april[1], I agree with you that the plan you outlined in April is pretty much the same plan that I think you are outlining now. In April you did agree that some RGB editing operations don't work in unbounded sRGB. You said that using targetRGB (ie the user's chosen RGB working space, UserRGB, barRGB, etc) would be one solution and that another solution would be converting to CIELAB to do the operation. 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: 1. Upon opening an image, the image will be converted to unbounded sRGB. 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. 3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing. 4. When converting to XYZ/CIELAB/etc, the image will first be converted to unbounded sRGB. 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. 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. Are the above five points (and note) an accurate summary of your current plan for babl/GEGL/GIMP? I have a couple of followup questions, but there's no point in asking them if I don't have a clear understanding of what your current plan really is. I think we've both been rightly accused of talking right past each other. 1: the only change in plans since then (and that changed occured before roadmap.txt was started), was abandoning the plan to do conversions between bablRGB and userRGBs in babl using LCMS2; and instead do those conversions directly ourselves in babl; a change without impact on how babl will be used by GEGL (and GIMP). Using babl instead of LCMS2 to do ICC profile matrix conversions makes perfect sense, being faster and potentially a lot more accurate (https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00093.html). /pippin 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] paint with color from gradient
But there is nothing in the matrix that says says Color from Gradient. The closest thing I can find is Random color. In gimp 2.6 there is a tick-box for Color from Gradient and it makes a graceful predictable gradual flow from one color to another. Can we still do that, in 2.8? Thank you, On Mon, Nov 17, 2014 at 1:43 AM, Olivier oleca...@gmail.com wrote: 2014-11-17 0:11 GMT+01:00 Helen etter...@gmail.com: I used to know how to paint with color from gradient. Various help sites say hoose the dynamics Color From Gradient, but I haven't been able to find that option. How can I use airbrush with Color from Gradient? Thanks, When the airbrush tool is selected, look in its options in the bottom part of the window. Click the icon on the left of Dynamics to open the menu of available dynamics. -- Olivier Lecarme -- Helen Etters using Linux, suse12.3 ___ 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] paint with color from gradient
On 11/17/14 07:49, Helen wrote: But there is nothing in the matrix that says says Color from Gradient. The closest thing I can find is Random color. In gimp 2.6 there is a tick-box for Color from Gradient and it makes a graceful predictable gradual flow from one color to another. Can we still do that, in 2.8? Hmmm, on my 2.8 version it's item #5 in the drop-down. In the matrix, it would be row 4 (color) and column 7 (fade). Are you seeing something different? On Mon, Nov 17, 2014 at 1:43 AM, Olivier oleca...@gmail.com wrote: 2014-11-17 0:11 GMT+01:00 Helen etter...@gmail.com: I used to know how to paint with color from gradient. Various help sites say hoose the dynamics Color From Gradient, but I haven't been able to find that option. How can I use airbrush with Color from Gradient? Thanks, When the airbrush tool is selected, look in its options in the bottom part of the window. Click the icon on the left of Dynamics to open the menu of available dynamics. ___ 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
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
Re: [Gimp-user] paint with color from gradient
ok thanks I finally found that. Playing with the fade length helps, but it still doesn't behave like Color from Gradient in 2.6. What should be in the text box to the right of the icon? I sit here with gimp 2.8 on my desktop and 2.6 on my laptop, same two colors, and I can't get 2.8 to make a smooth gradual transition like 2.6 does. I'm trying different settings in the text box to the right of the icon. Fade tapering seems to get the closest. On Mon, Nov 17, 2014 at 10:22 AM, Gary Aitken a...@dreamchaser.org wrote: On 11/17/14 07:49, Helen wrote: But there is nothing in the matrix that says says Color from Gradient. The closest thing I can find is Random color. In gimp 2.6 there is a tick-box for Color from Gradient and it makes a graceful predictable gradual flow from one color to another. Can we still do that, in 2.8? Hmmm, on my 2.8 version it's item #5 in the drop-down. In the matrix, it would be row 4 (color) and column 7 (fade). Are you seeing something different? On Mon, Nov 17, 2014 at 1:43 AM, Olivier oleca...@gmail.com wrote: 2014-11-17 0:11 GMT+01:00 Helen etter...@gmail.com: I used to know how to paint with color from gradient. Various help sites say hoose the dynamics Color From Gradient, but I haven't been able to find that option. How can I use airbrush with Color from Gradient? Thanks, When the airbrush tool is selected, look in its options in the bottom part of the window. Click the icon on the left of Dynamics to open the menu of available dynamics. -- Helen Etters using Linux, suse12.3 ___ 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] I need the Gimp 2.9 where i can find ??
Am 17.11.2014 um 13:43 schrieb Michael Schumacher: Von: Thorsten Stettin thorsten.stet...@gmail.com Hi Thorsten, you can use https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge sudo apt-get install gimp it would be nice if packages for the development branch would give users the ability to keep the current stable GIMP installed as well - being able to compare the behavior of the two is one of the points of installing a development version. If the 2.9.x package wouldn't be called gimp, but e.g. gimp-2.9 (or something similar, if this name doesn't correspond to Debian/Ubuntu package naming policies), this could be achievable. Ok, but IMHO it takes some time. O:-) -- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen. ___ 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] I need the Gimp 2.9 where i can find ??
Am 17.11.2014 um 13:43 schrieb Michael Schumacher: Von: Thorsten Stettin thorsten.stet...@gmail.com Hi Thorsten, you can use https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge sudo apt-get install gimp it would be nice if packages for the development branch would give users the ability to keep the current stable GIMP installed as well - being able to compare the behavior of the two is one of the points of installing a development version. If the 2.9.x package wouldn't be called gimp, but e.g. gimp-2.9 (or something similar, if this name doesn't correspond to Debian/Ubuntu package naming policies), this could be achievable. What will be the name of the upcoming babl version? babl 0.11 or 0.2? It's very important for the packaging regarding a parallel installation of Gimp 2.8 and Gimp 2.9. Thanks -- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen. ___ 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] I need the Gimp 2.9 where i can find ??
Am 17.11.2014 um 13:43 schrieb Michael Schumacher: Von: Thorsten Stettin thorsten.stet...@gmail.com Hi Thorsten, you can use https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge sudo apt-get install gimp it would be nice if packages for the development branch would give users the ability to keep the current stable GIMP installed as well - being able to compare the behavior of the two is one of the points of installing a development version. If the 2.9.x package wouldn't be called gimp, but e.g. gimp-2.9 (or something similar, if this name doesn't correspond to Debian/Ubuntu package naming policies), this could be achievable. What will be the name of the upcoming babl version? babl 0.11 or 0.2? It's very important for the packaging regarding a parallel installation of Gimp 2.8 and Gimp 2.9. Thanks -- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen. ___ 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
[Gimp-user] Question about golden-spiral-0.0.py script
Hi, I've got GIMP 2.8 on OSX Mavericks and I'm trying to use this script: http://sourceforge.net/projects/gimp-path-tools/files/scripts/golden-spiral-0.0.py/download I've tried putting it in /Users/myusername/Library/Application Support/GIMP/2.8/scripts and in /Users/myusername/Library/Application Support/GIMP/2.8/plugins. I have verified that both of those paths are set in the GIMP Prefeferences/Scripts and /Plug-ins settings. Either way, I get no errors when starting GIMP and I can't find the menu options to use the golden spiral in GIMP. Am I doing something wrong? Thanks, Dave ___ 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 are
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 ellest...@ninedegreesbelow.com 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
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 Mon, Nov 17, 2014 at 11:56 PM, Simon Budig si...@budig.de 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] Question about golden-spiral-0.0.py script
I don't know about OSX, but the python script needs python support, you have python installed? In the unix world, the script needs to be executable, is this the case for you? Python scripts go in the users plug-ins subdirectory, not in scripts Owen Sent: Monday, November 17, 2014 at 11:54 AM From: Dave Thibault d...@thibaultfineart.com To: gimp-user-list@gnome.org Subject: [Gimp-user] Question about golden-spiral-0.0.py script Hi, I've got GIMP 2.8 on OSX Mavericks and I'm trying to use this script: http://sourceforge.net/projects/gimp-path-tools/files/scripts/golden-spiral-0.0.py/download I've tried putting it in /Users/myusername/Library/Application Support/GIMP/2.8/scripts and in /Users/myusername/Library/Application Support/GIMP/2.8/plugins. I have verified that both of those paths are set in the GIMP Prefeferences/Scripts and /Plug-ins settings. Either way, I get no errors when starting GIMP and I can't find the menu options to use the golden spiral in GIMP. Am I doing something wrong? Thanks, Dave ___ 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 ___ 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 ellest...@ninedegreesbelow.com 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:
