Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 10/08/2014 04:20 PM, Øyvind Kolås wrote: On Wed, Oct 8, 2014 at 9:49 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On Wed, Oct 8, 2014 at 4:25 PM, scl scl.gp...@gmail.com wrote: The we have to juggle a large set of different types of pixel formats already? The initial thinking was that linear working in RGB and HDR was sufficient, that is what the current babl is sufficient for, one uses ICC based conversions to get into the internal formats which are supposed to have efficient management, programming naming and conversions. And uses an external CMS for interacting with the outside. As Elle has repeatedly pointed out, that is not sufficient; and the scope of what is considered natively juggled pixel formats must be extended. The babl/GEGL/GIMP code base has a relatively short list of places where hard-coded sRGB parameters are used. I've already identified most such code. Most of it uses sRGB Y values. Each location that says babl_format(RGBA foo) or babl_format (R'G'B'A foo) or babl_format (RaGaB..) etc. is a location that requests a specific format. It is not the places in the code that implements the sRGB primaries which is in question. To generalize such code to work with all RGB working spaces, replace hard-coded sRGB Y values with Y values retrieved by LCMS from the user's chosen RGB working space colorant XYZ values. The Y values can be retrieved upon opening an image and again upon switching images for users who have several images open at once. To somewhat simply, ICC RGB working space profiles are characterized by: 1. The profile Red, Green, and Blue colorant XYZ values, aka primaries. 2. The profile Tone Reproduction Curve, TRC for short. Right now, when a user opens a regular ProPhotoRGB image, the primaries AND the TRC are not what the babl/GEGL/GIMP code expects (the regular ProPhotoRGB TRC is Gamma=1.8). The only operations that *don't* produce wrong results are operations that don't use sRGB primaries AND don't linearize the sRGB TRC. You can make an ICC profile using any primaries and any TRC. For example, a profile can be made using the ProPhotoRGB primaries and the sRGB TRC. So here is one way to make the current hard-coded sRGB TRC-based transforms between linear and perceptually uniform RGB work: Upon opening an image, use LCMS to make a profile using the user's chosen primaries and the sRGB TRC, and convert the image to this new profile. Once. Not repeatedly back and forth. And of course replace all the code that uses hard-coded sRGB primaries. I have two questions about the linear-to-perceptual babl TRC flips code: 1. Is it acceptable to mess with a user's RGB data by keeping the primaries intact and only modifying the TRC? A user who expects their data is encoded using the ProPhotoRGB gamma=1.8 TRC will not fail to notice that data encoded using the sRGB TRC gives different results. The babl TRC flips code could be modified to give the user a choice of TRCs for encoding perceptually uniform RGB. 2. Does the repeated linear-to-perceptual-to-linear babl TRC flips required by the current architecture impose a loss of precision? How much loss, after how many flips? What you are describing is exactly what I outlined API for elsewhere. You would.. babl_set_named_rgb_chromaticities (babl, hack, colorants.. and you would get what you want by having replacing all occurences of RGBA float and R'G'B'A float with hack:RGBA float and hack:R'G'B'A float, and the same for u8 and u16. I'm not proposing that you use sRGB as PCS and then hack the code to fix the resulting problems. I'm proposing that you eliminate sRGB as PCS altogether. It's a broken model for RGB editing. The VFX people understood with *one* multiply example that there can be no universal RGB working space. The best working space depends on the artistic intent plus the device(s) that produced the colors, and eventually on the device(s) on which the colors will be displayed. Adobe-centric advice implies that color gamut is the only consideration when choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries into their raw processing software. It is distressing to see GIMP follow Adobe's lead by writing code on the assumption that the sRGB primaries are suitable for editing all images. But the R'G'B'A u8 and u16 and similar better be left alone because they have been written with the assumption that their data is sRGB. If there is code for 8-bit and 16-bit integer images that uses sRGB *primaries*, that code needs to be rewritten or removed. It makes no sense in the context of a high end, high bit depth image editor. Globally switching it upon switching images does not work for copy and paste between images and other forms of work where different spaces might be at play. Copy-paste/drag-drop do require converting the pixels from the source layer stack's ICC profile to the destination layer stack's ICC profile. That's what properly
Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise
Hi Pippin, I hope you don't see my lines as picking on your work, but as the constructive criticism as it is meant. GIMP has performance issues, especially with large images and modern camera sensors are just delivering them. On 8.10.2014 at 4:47 PM Øyvind Kolås wrote: On Wed, Oct 8, 2014 at 4:25 PM, scl scl.gp...@gmail.com wrote: 1) Extra conversions every now and then produce overhead - increase computation time - decrease performance. One part of GIMP's product vision is [high working speed] and I don't see how extra overhead can speed up things. And I would not claim GIMP and GEGL to be tigers, especially when it comes to large images. Babls conversions are often transparent since they occur where data is copied anyways and memory access is more expensive - the ones doing unpremultiplication of alpha being among the exceptions (as well as when we end up hitting reference paths where we are starting to use new and not even attempted optimized combinations of formats.) What I don't see is not there? - Let's not put the head in the sand. The point is not whether they are transparent or not, but whether they are necessarily done or not. Also, how does memory access instead of converting come in here? For example adjusting brightness and contrast with preview of a 5184x3456 px photo happens immediately in PS CS5 (from 2010). GIMP 2.8.14 takes 7 seconds and the GEGL tool 'brightness-contrast' takes 16 seconds for the same image on the same machine. Performance is a concern, but it is different parts of the architecture that needs improvement for that type speed up... With a GEGL GUI that is not GIMP I've experimented with the new mip-map rendering capabilities recently added to GEGL and previewing of on canvas brightness contrast or gaussian blur/unsharp mask on a 1x5000 image is instant (it processes somewhere between the number of pixels on screen and 4x that, not more). Allowing you to both adjust the op, pan and zoom at will. This is a display trick to give the user immediate control (and a good idea for GIMP, too). However, the whole image has to be processed anyway. Display tricks can hide an underlying problem, but not solve it. I also think that it should be the user's decision whether s/he wants to apply an operation to a coloured image, a grayscale image or a mask. Leaving this decision solely to the developer (who's not necessarily an artist) doesn't satisfy the claim to be a high-end image manipulation program. That decision is not set in stone because of the format asked for by the GEGL operation, it is the task of GIMP on top of GEGLs abstractions to provide the means to do so. ...which ends up in refusing the op or converting the data and the circle closes here. Or is there something else? Therefore I think it's better to let all operations work on the same appropriate colour space (big enough and computable precisely and efficiently) and do conversions only on the interfaces to the outside world: importing and exporting images, displaying, working with ICC profiles etc. IIRC there was a hint on that in one of the former posts to this topic - what where the reasons to not to do so? The we have to juggle a large set of different types of pixel formats already? I thought of the same (=a common) colour space for all ops, leading to a commonly shared pixel format which makes conversions unnecessary. You and Elle are the right people to find that space and fine tune its implementation and I hope you both are open enough to find a good solution together. Kind regards Sven ___ 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/09/2014 11:04 AM, scl wrote: I thought of the same (=a common) colour space for all ops, leading to a commonly shared pixel format which makes conversions unnecessary. If I misunderstood what you just said, my apologies. But I think you've concluded that because sRGB is so small, therefore the out of gamut colors are the only problem with using sRGB as a universal color space. That is not what I've been trying to explain. That's just an extreme and easily demonstrated problem with sRGB as a universal color space. There is no such thing as a universal RGB color space suitable for editing all images, produced by all devices, for display on all devices, for all possible artistic intentions. The problem with multiply is *not* just that multiplying out of gamut colors produces meaningless results. The problem with multiply is also that performing multiply in different color spaces produces different results. The usefulness of the results in one RGB color space vs another RGB working space depends *entirely* on what the user wants to accomplish by multiplying colors together. For instance, in Color space A, you can't use Levels to white balance away a color cast that was created in Color space B. It just can't be done: http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html Channel data is completely changed by converting from one set of primaries to another. Things you can do with channel data in one color space become entirely impossible after converting to another color space: http://ninedegreesbelow.com/photography/unbounded-srgb-channel-blend-convert-black-white.html There is no universal color space. Out of gamut colors are not the only problem. ACES is not a universal color space, although it mitigates the problem of out of gamut colors. The Identity color space, which I did mention a couple of years ago, is not a universal color space, although it mitigates the problem of out of gamut colors. I say mitigates, not solves, as cameras have a nasty habit of not reproducing colors exactly the way people see them. Saturated yellows can be out of gamut as interpreted by camera matrix input profiles. You have to consider the source of the data, what devices the data will eventually be displayed on, and the artist's reasons for manipulating it. Compositing data from different sources together as one image is the very *last* step in a well-defined, carefully thought out workflow. First you do whatever needs to be done in the source color space(s) to get the colors the way you want them to be. You can't code an image editor on the basis of making drag and drop easier. You have to convert the pixels from the source to the destination color space. Krita does it. Surely GIMP can do it too. There is not and cannot be, a universal color space suitable for editing all images, for all artistic intentions. You and Elle are the right people to find that space and fine tune its implementation There is no such space. Therefore you can't fine tune its implementation. It doesn't exist. and I hope you both are open enough to find a good solution together. This has nothing to do with being open to finding a good solution together. You can't base an image editor around making it easy to drag colors from one layer stack to another. There is no universal color space suitable for all image editing tasks. With respect, 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] Don't make an architectural mistake based on a groundless premise
On Thu, Oct 9, 2014 at 8:00 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: To somewhat simply, ICC RGB working space profiles are characterized by: 1. The profile Red, Green, and Blue colorant XYZ values, aka primaries. 2. The profile Tone Reproduction Curve, TRC for short. Right now, when a user opens a regular ProPhotoRGB image, the primaries AND the TRC are not what the babl/GEGL/GIMP code expects (the regular ProPhotoRGB TRC is Gamma=1.8). The only operations that *don't* produce wrong results are operations that don't use sRGB primaries AND don't linearize the sRGB TRC. Yes, the current color management is somewhat unfinished and broken with respect to importing/exporting. Nobody claimed that is was correct. It does not implement the planned design yet. You can make an ICC profile using any primaries and any TRC. For example, a profile can be made using the ProPhotoRGB primaries and the sRGB TRC. So here is one way to make the current hard-coded sRGB TRC-based transforms between linear and perceptually uniform RGB work: Upon opening an image, use LCMS to make a profile using the user's chosen primaries and the sRGB TRC, and convert the image to this new profile. Once. Not repeatedly back and forth. Yes, on import, we should definitely convert the TRCs. We don't do this right now because the code isn't finished. And of course replace all the code that uses hard-coded sRGB primaries. The idea is to not completely replace the sRGB code, but just add a new code path that supports RGB spaces with different primaries. See my remarks below. I have two questions about the linear-to-perceptual babl TRC flips code: 1. Is it acceptable to mess with a user's RGB data by keeping the primaries intact and only modifying the TRC? A user who expects their data is encoded using the ProPhotoRGB gamma=1.8 TRC will not fail to notice that data encoded using the sRGB TRC gives different results. The babl TRC flips code could be modified to give the user a choice of TRCs for encoding perceptually uniform RGB. We were planning to include support for a choice between linear RGB w/ user primaries and sRGB-TRC RGB with user primaries, with the idea that both a perceptual and a linear space is enough to support all the required editing operations. Then, many operations which only make sense with a given TRC would specifically use that TRC. For example, downscaling might do a conversion so it always happens in linear space. 2. Does the repeated linear-to-perceptual-to-linear babl TRC flips required by the current architecture impose a loss of precision? How much loss, after how many flips? Yes, there is a small loss in precision. I think Daniel Sabo did some tests to try and exactly quantify the error a while back, although I forget the results. This certainly is a concern though, and work has been done to minimize the error in conversions. That being said, the operations themselves don't exactly have infinite precision either; nearly any floating point computation has the potential to throw away some data. The simple act of adding two numbers in floating point can throw away data (I can provide examples, if you're interested). To some degree you just need to live with that fact in any floating point image editor. What you are describing is exactly what I outlined API for elsewhere. You would.. babl_set_named_rgb_chromaticities (babl, hack, colorants.. and you would get what you want by having replacing all occurences of RGBA float and R'G'B'A float with hack:RGBA float and hack:R'G'B'A float, and the same for u8 and u16. I'm not proposing that you use sRGB as PCS and then hack the code to fix the resulting problems. I'm proposing that you eliminate sRGB as PCS altogether. It's a broken model for RGB editing. The VFX people understood with *one* multiply example that there can be no universal RGB working space. The best working space depends on the artistic intent plus the device(s) that produced the colors, and eventually on the device(s) on which the colors will be displayed. I'm not entirely clear which concept you're trying to refute in that section. sRGB as a PCS, or sRGB as a universal working space? They're two different concepts, and while you said sRGB as a PCS, you arguments seem to be about sRGB as a working space to me. Øyvind's proposal is no longer to have a universal working space. sRGB would remain in babl as the PCS, but the results of the color conversions would be indistinguishable from if we chose, say XYZ as a PCS. Ie, babl will support your suggestion (user-chosen primaries with either linear or sRGB TRC) in addition to sRGB, instead of replacing sRGB. Gimp/gegl will then switch to using the working space profile instead of always using sRGB. Having sRGB still around won't make a big difference from the user's standpoint, but it makes the code a little nicer. Adobe-centric advice implies that color gamut is the only consideration when
[Gimp-developer] ERROR???GIMP, Ubuntu-System? or?
Hello GIMP-Team, what's that? Kind regards, Stephan Siebert -- Stephan Siebert Silbersteinstraße 138 12051 Berlin Telefon: 030.8645.5886 E-Mail: stephan.sieb...@kabelmail.de ___ 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] ERROR???GIMP, Ubuntu-System? or?
What is what? :) Is there a screenshot or an error log you intended to share with us? Alex On Thu, Oct 9, 2014 at 10:18 PM, stephan.sieb...@kabelmail.de wrote: Hello GIMP-Team, what's that? Kind regards, Stephan Siebert -- Stephan Siebert Silbersteinstraße 138 12051 Berlin Telefon: 030.8645.5886 E-Mail: stephan.sieb...@kabelmail.de ___ 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] Don't make an architectural mistake based on a groundless premise
On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: My assumption was that sRGB as PCS only made sense in the context of using unbounded sRGB as a universal working space. If sRGB as PCS means that unbounded linear gamma sRGB is used to convert from RGB to XYZ to LAB, for example, then I'm not sure when sRGB as PCS would be used. For example, for converting to LAB, use the user-chosen primaries (colorants) to convert to XYZ and then to LAB. See below. Ie, babl will support your suggestion (user-chosen primaries with either linear or sRGB TRC) in addition to sRGB, instead of replacing sRGB. Does in addition to sRGB mean duplicate code files side by side, one set of files hard-coded for just sRGB images and one using Y and XYZ values retrieved from the user's chosen primaries? For example, the babl code that converts from color to Luminance for painting on a mask would be duplicated, once for sRGB and once generalized? To some degree, yes. We don't need to recreate every single transformation. For example, when converting from some arbitrary RGB color space to luminance, we can chain the conversions: first, one conversion from the user-specified RGB space to linear sRGB, and then from linear sRGB to luminance. If that's too slow, we also have the option of defining fast paths that convert directly between two color spaces, but the core of babl always converts to linear sRGB as an intermediate. This is what we mean when we say sRGB as PCS: all of the color formats are defined in terms of linear sRGB, so if a given transformation hasn't been coded specifically, we can use linear sRGB as an intermediate. Also, some portions of sRGB will probably share code with the generic RGB code. But, the important point is that we want sRGB to still exist within babl as a usable, built-in format. Adobe-centric advice implies that color gamut is the only consideration when choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries into their raw processing software. It is distressing to see GIMP follow Adobe's lead by writing code on the assumption that the sRGB primaries are suitable for editing all images. I'll repeat that the sRGB primaries won't be the only supported working space. You talked us out of that idea a long time ago. Oh. I didn't realize that. Maybe we weren't too clear. :P The temperature change code produces very pleasing results for sRGB images, much nicer than another editor that I tried. Based on eyedroppering and comparing to spreadsheet calculations, the colors aren't colorimetrically correct and maybe they never were intended to be. On the other hand, I only checked Bradford adaptation and I'm not 110% certain I handled all the matrix math correctly. The current code uses hard-coded coefficients based on sRGB primaries and produces obviously wrong results for non-sRGB images. Bradford/CAT02 etc chromatic adaptation code would seem to be a logical generalized replacement. This article demonstrates using CAT02 to do color temperature corrections: http://nbviewer.ipython.org/gist/kelsolaar/7098c6709c59b9afb018 The article uses the D65 sRGB color space, not the D50-adapted sRGB ICC profile color space, but it illustrates the math nicely. Okay, we should probably look at that then. From, Mike Henning ___ 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
