Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On 10/11/2014 08:52 PM, Jon Nordby wrote: Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. Is the above correct? Kind regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On 11 October 2014 13:41, Elle Stone wrote: > On 10/10/2014 07:49 PM, Øyvind Kolås wrote: > >> >> This is not about how images with no embedded profile are handled. >> sRGB derived 8bit (and to a lesser degree 16bit) formats are used for >> many other things than images with no embedded profile. >> > > You falsely assume that 8-bit images are always sRGB images and that > 16-bit integer images are probably sRGB images. > No-one said always. sRGB is however the most common for 8-bit images. > These pixel >> formats are crucical for integrating with existing file formats and >> libraries; >> > > File formats that only work with sRGB images should not impact > color-managed image editing. Advise the user to convert to sRGB. > > Accurate UI colors is a desktop color management issue, entirely > irrelevant to programming a color-managed image editor. > The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. -- Jon Nordby - www.jonnor.com ___ 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] Plugins
To whom it may concern, I am a Gimp user trying to find a way to create a plugin for DAZ Studio 4.6 DAZ offers Studio and a Photoshop plugin for free. Is there any way to make one for Gimp, or can Gimp even handle 3D like Photoshop? Thank you for your time, Charlie M. ___ 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] Don't make an architectural mistake based on a groundless premise
On 10/10/2014 05:01 PM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: You cannot get from "sRGB as PCS" to LAB without first converting from "sRGB as PCS" to XYZ. LAB is a mathematical transform of XYZ, not sRGB. This is the normal path from User_RGB to LAB: User_RGB -> XYZ -> LAB. Two conversions. You want to take this path, yes? User_RGB -> XYZ -> "sRGB as PCS" -> XYZ -> LAB. Four conversions, going through XYZ twice. [I am most likely talking about stuff that you already know, but it might be worth reiterating to keep the discussion understandable for people not that deep in the topic] Note that - as long as we're talking about linear RGB spaces (which pure sRGB is not, but AFAIK we're talking about "linear RGB with the sRGB primaries" here) - all but the last conversions in your chain boil down to applying a matrix to a vector. You can easily multiply these matrices together to build a matrix that does the first three conversions in a single operation. Simon, my apologies. Pippin has pointed out that I didn't repond to your email. Yes, I do realize that you can concantenate matrix conversions. I acknowledged that in a reply to Pippin, but I should also have acknowleged your input. Again, my apologies. I didn't mean to ignore you. Kind regards, Elle Stone ___ 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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
> Please provide a specific example of an actual CMM in an ICC profile > workflow that doesn't use XYZ for converting between RGB working spaces. Please read simons post about matrix multiplication, in his camera example the data never exists as XYZ. > You falsely assume that 8-bit images are always sRGB images and that 16-bit > integer images are probably sRGB images. This is not being assumed, but it is a matter of fact that a lot of buffers are in these formats and we want to deal well with them. >> formats are crucical for integrating with existing file formats and >> libraries; > > File formats that only work with sRGB images should not impact color-managed > image editing. Advise the user to convert to sRGB. The data needs to be loaded into a GeglBuffer with a BablFormat that uniqely describes the color content. For 8bit sRGB with babl that has traditionally been "R'G'B' u8", in the roadmap in babl I even suggested that the buffers data is loaded into should be changed to be "sRGB:R'G'B' u8" for clarity even if it will continue to mean the same as "R'G'B' u8". And the chromaticity/working/target space should also be set to "sRGB:R'G'B'". > Unbounded linear gamma sRGB is not a Profile Connection Space. > > Idiosyncratic redefinitions of well-established color management terms > confuses people who don't understand ICC profile color management. > > Idiosyncratic redefinitions of well-established color management terms makes > it difficult for people who do understand ICC profile color management to > communicate with the babl/GEGL devs. There are differences between the internal implementation of a system and the public API. Calling the bablRGB a PCS, since that is the role it has in the internal implementation was an attempt at making you understand the architecture, and I guessed you did understand since you have been using the term as well. I thought you would understand how XYZ fills the same role in ICC. It is never called either XYZ nor PCS in the babl code. It is better if we call it bablRGB than linear sRGB which is an oxymoron. > Is there any point in my demonstrating how convoluted and unworkable it will > be to convert to unbounded sRGB whenever Y is involved? Because if there > isn't, I don't want to waste my time. > > For a moment it seemed that perhaps unbounded sRGB was going to be dropped > and we could move on to generalizing the code to use Y and XYZ taken from > the user's chosen RGB working space > (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html). I was hinting at how a given set of chromaticities wouldn't be affecting single babl formats but change interpretation of also other formats when given a prefix. You seem to challenge mention of sRGB to the extent that people have been championing linear workflows. While bablRGB will end up being an implementation detail that is an optimization. Babl will end up having _many_ different RGB spaces with associated grayscale format; at some point probably also associated non-linear spaces but that will have lower priority. Among these spaces will be a space called sRGB which behaves like the unprefixed formats. When we have these spaces. When we have these additional spaces - what I have suggested is that we then mark the operations which _are_ chromaticity dependent to operate in this space. I have also hinted at what we might want to do, or at least which things would be possible to do - including getting rid of all unprefixed formats, as well as the possibility that such things could be decided dynamically. There is a lot of code in GIMP that we intend to keep working as we move forward, the only way is by small incremental changes while keeping things working, changing as few assumptions as possible as move move along. /Ø ___ 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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On Sat, Oct 11, 2014 at 1:41 PM, Elle Stone wrote: > As I have indicated before, the invitation is very kind. But not everyone is > able to drop other obligations and go to LGM. >> until then I prefer IRC. > > Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither > pleasant nor productive. That is an apt summary of this email exhange as well, neither pleasant nor productive - sorry. At least on IRC there is the chance of correcting misunderstanding before they've been published as books. The only reason I have responded in this thread is that "someone is wrong on the internet" and was spreading fundamental misunderstandings about how babl works as well as how we intended it to be used in GEGL in the future, I wish that time had been spent implementing it instead. Many of the questions in your later e-mail have been responded to in other emails preceding your emails. I find it ironic that the architecture that you question is the architectural foundation that ICC also is using. With similar constraints and performance characteristics. /Øyvind ___ 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] Don't make an architectural mistake based on a groundless premise
On Sat, Oct 11, 2014 at 12:08 AM, Øyvind Kolås wrote: >> You want to take this path, yes? User_RGB -> XYZ -> "sRGB as PCS" -> XYZ -> >> LAB. Four conversions, going through XYZ twice. >> >> Why is the second path preferable? > > Forget about CIE Lab No way. Alex ___ 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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On 10/10/2014 07:49 PM, Øyvind Kolås wrote: On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone wrote: So I have two specific questions. The first question is about converting to LAB. The second question (which I haven't asked yet) has to do with Y. We will try to do what makes sense and helps us achieve what we need to achieve efficiently; while keeping what works well, working well. The above statement is devoid of content. It serves to dismiss my specific questions about why you want to keep hard-coded sRGB XYZ and Y in a color-managed workflow. "sRGB as PCS" is linear gamma unbounded sRGB. I think it's reasonable to ask why a conversion to unbounded sRGB should be involved in a conversion from User_RGB to LAB. For the same reason XYZ is involved (or not, depending on how the CMM does it) in an ICC workflow. Please provide a specific example of an actual CMM in an ICC profile workflow that doesn't use XYZ for converting between RGB working spaces. Existing code written with assumptions of sRGB, whether in GIMP and GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB assumed will continue to work. We take the existing architecture which is following general guidelines of assuming sRGB where none is specified. A guideline for dealing with images that don't have embedded ICC profiles makes an appalling bad guideline for writing a color-managed image editor. This is not about how images with no embedded profile are handled. sRGB derived 8bit (and to a lesser degree 16bit) formats are used for many other things than images with no embedded profile. You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images. These pixel formats are crucical for integrating with existing file formats and libraries; File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB. Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. and we want these conversions to be as fast as possible - even if it might have an impact on the conversion speed for CIE Lab, though that does not have to be the case either. Choosing any PCS *but* linear sRGB into a PCS would tend to make these important conversions slower. Unbounded linear gamma sRGB is not a Profile Connection Space. Idiosyncratic redefinitions of well-established color management terms confuses people who don't understand ICC profile color management. Idiosyncratic redefinitions of well-established color management terms makes it difficult for people who do understand ICC profile color management to communicate with the babl/GEGL devs. I can move on to my question about Y and unbounded sRGB. But I still don't understand why unbounded sRGB should be involved in a conversion from User_RGB to LAB. We will do what makes most sense and is neccesary when we get there, I suspect each RGB model with have an associated Y and YA model. Due to how the existing BablModels interact with components and vocabulary used to address them in babl; potential support for different TRCs is even vaguer; we'll know when we have more code. Is there any point in my demonstrating how convoluted and unworkable it will be to convert to unbounded sRGB whenever Y is involved? Because if there isn't, I don't want to waste my time. Maybe we have more code by the time of LGM, if not that would be an excellent place to elaborate; As I have indicated before, the invitation is very kind. But not everyone is able to drop other obligations and go to LGM. until then I prefer IRC. Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither pleasant nor productive. For a moment it seemed that perhaps unbounded sRGB was going to be dropped and we could move on to generalizing the code to use Y and XYZ taken from the user's chosen RGB working space (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html). However, given Pippin's latest explanations of how things will be done, I'm not sure there's any point in my continued involvement with GIMP development. Kindest regards, Elle Stone ___ 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
