Re: [Gimp-developer] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors
Hi! On Fri, Feb 5, 2021 at 1:00 AM Elle Stone wrote: > A misconception I keep seeing on various forums needs to be corrected: > > GIMP-2.10 does *NOT* produce correct editing results in color spaces > other than sRGB. Neither does GIMP-2.99. > > Editing in AdobeRGB, ProPhotoRGB, Rec2020, etc WILL produce *wrong* > results for many operations, and unless you are thoroughly conversant > with the underlying code, or else have a way to compare results with a > properly color-managed editing application, you don't have any way to > know what's right and what's wrong. It's best to stick with editing only > in GIMP's built-in sRGB color spaces. > > The same is true if you are using GIMP-2.99: Some things that don't work > in GIMP-2.10, do work in GIMP-2.99. Other things that actually do work > in GIMP-2.10, don't work in GIMP-2.99. > > About two years ago major changes were made in babl and additional > changes were made in GIMP-2.99, messing up stuff that still works in > GIMP-2.10. For awhile progress was being made in GIMP-2.99 on extending > the arena of "what actually works", some of which progress is from bug > reports I filed and in some cases helped to fix - it seems nobody else > was testing the new code to see what actually did work. > > I was able to write code that fixed some of the bugs I reported for > GIMP-2.99 color management. But once I reached the point where further > coding requirements exceeded my coding ability, progress simply stopped, > with everyone else saying "some day" proper color management for GIMP > would be a priority. I began to feel like the best way to make sure a > bug would never get fixed, was to have the dreaded "Concepts: Color > Science" tag attached to it. > > Since autumm of 2013 I've been participating in GIMP development, mostly > in the area of color management (editing in color spaces other than > sRGB) and color science (making sure GIMP code produces correct results > for things like layer blend modes, Curves and Levels, AutoStretch, > Luminance, and so on; and adding code for things like LCh color pickers > and blend modes). > > Participating in GIMP development used to be challenging and enjoyable. > But over the last couple of years my interest in and patience with the > slow pace of progress regarding GIMP color management have dwindled to > the point of disappearing altogether. > > If someone else feels like helping with GIMP color management and color > science, here's a list of still-open bug reports that I reported after > the migration to gitlab, most of which have to do with color > management/color science: > > > https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_username=ellestone > > Here are bugs that I opened before the migration to gitlab: > > https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_username=bugzilla-migration=ellestone > > The most important color management bugs still open from before the > migration to gitlab are these: > > * Replace hard-coded sRGB parameters to allow editing in other RGB > working spaces (opened 6 years ago): > https://gitlab.gnome.org/GNOME/gimp/-/issues/594 - in some ways this bug > is obsolete as current GIMP color management issues are less about > actual hard-coded values and more about a lack of any way to convey the > required "not sRGB" color space information to various sections of code > that need this information. > > * Decomposed to LAB images have the wrong ICC profile assigned (opened 4 > years ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/883 > > * Address various limitations of LCMS soft proofing (opened 4 years > ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/976 > the > and hoping very much that GIMP will find new developers that them a lot > of energy and some interest and expertise in color management and color > science. > * Support for high bit depth RGB (and LCH?) color palettes for painting > (opened 2 years ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/1328 > > Similar searchs in https://gitlab.gnome.org/GNOME/gegl/ and > https://gitlab.gnome.org/GNOME/babl/ will turn up a few additional color > management issues. > > Best of luck to all, > So it feels like you are saying goodbye. If so I hope it's only a temporary one and you'd be back if we get more active on the color management side. We will, we definitely will, because it's a major part of what GIMP 3 is supposed to be about anyway. I personally have a high theoretical interest on this topic, but not a practical one unfortunately (because we work in sRGB), which is why it is both high in priority for me (because we need it for GIMP 3) and low (compared to what we actually do day to day with GIMP). I have always been hoping that Mitch and Ell would be back soon as they are much better suited than me to decide on these topics anyway IMO. These are actually very intimidating topics. I do understand them (or so I believe), when scratching the head very hard, but I feel much
Re: [Gimp-developer] Discuss backward compatibility for multilayer changes to v3 PDB API
Hi! On Sun, Feb 7, 2021 at 5:59 PM Lloyd Konneker via gimp-developer-list < gimp-developer-list@gnome.org> wrote: > The v3 PDB API has changes for multilayer capability. > For example this signature change: gimp-edit-copy(drawable) => > gimp-edit-copy(drawableArray). > This breaks some scripts in the GIMP repository and some third party > plugins. > > To provide backward compatibility means allow existing scripts to work for > a defined period. > (say from 2.99 until 3.1). > Just for the record, there are no such versions: 2.99 and 3.1. Or to be accurate, these are dev versions, they don't "count". Whatever is in 2.99 and whatever will be in 3.1 doesn't matter but for testing. We don't mind too much broken stuff in these (we obviously prefer non-broken stuff, but this won't stop us from releasing something for people to test the rest, i.e. what is not broken). As for API in particular, it means that API compatibility is a non-existent concept there. We are heavily testing. The API may end up broken even between 2 micro releases (like 2.99.4 to 2.99.6). This is what these versions are for. What matters is only that we get the right API for GIMP 3.0. That allows users time to adjust their scripts. > It had been decided long ago that the API could break for our GIMP 3.0 release. I mean, the multi-layer related functions you give are only the tip of the iceberg. There are so many more changed functions, and in particular all the base API for plug-ins are changed anyway. Now the old base API don't even exist anymore. So anyway all plug-ins will have to be updated. It's not even an "if" anymore, and it's not even related to multi-layer selection (even without this, all plug-ins will have to be updated). I mean, it's already too late. We have not just started or anything. This work on base API changes started more than 2 years ago (after we released GIMP 2.10.0) and reverting this (losing 2+ years of work by several people and using probably just as much to bring compatibility back) is not an option as far as I'm concerned! > If we don't provide backward compatibility, it is a logistics problem: > third party script authors must prepare an updated copy of their scripts, > and change over immediately when they change from 2.10 to 3.0. > Which is also why we have started to talk about this long before, made news about this on GIMP website and we started to release dev versions. The current dev API is unstable (as already said), but it's still close to what will be released as stable. So plug-in developers are very welcome to start porting. Whatever will change between now and finale stable GIMP 3.0 likely won't be as much as what already changed between 2.10 and current dev version. We also plan to document the main changes, with porting docs, tutorial and whatnot. And also we hope to have the new extension platform by the time we release GIMP 3, to help people port their plug-ins and upload them. In the end, the change won't be so complicated. It may look scary, but in the end, I don't think even the most complicated plug-ins will need much more than 30 min to be ported. Ok maybe 1hour if rlly you made a hugely complicated plug-in, I don't know. Talking from experience of having participated to port many of our core plug-ins. > Some scripts in GIMP 2.99 are broken now since the API was changed but > scripts were not updated. > If we provide backward compatibility, > the GIMP developers can fix the scripts in the repository at their leisure. > Are you talking about third-party scripts or the ones we provide? If the core ones, of course we should port them before release. But not providing a compatibility layer again. As said, GIMP 3 is our chance to improve our API, 25 years of cruft, 25 years of evolution, new features, new usages, so many things different. The goal is not to continue with double the mess. Like if we talk about multi-layer related API, what? Do we want to propose every layer API in double now? Both multi and single layer? Then do the same when we finally make vectors and channels multi-selectable? I'm not saying what you say is wrong. Of course, in an ideal setup, we try to never break any past API. But in this ideal setup, we are more than a handful of contributors. Right now, trying to do what you propose would be like releasing GIMP 3.0 in 5 years. I don't think anyone wants this. So yeah this is why we just decided long ago that API breakage was allowed as it was a major version update. We don't do useless API breakage, but for stuff like multi-layer selection, this just makes sense. It will be a new ability of GIMP 3. Nobody wants our API not to be able to access this feature. And we don't want to maintain double the functions. > Because the name has stayed the same but the signature changed, > to provide backward compatibility could be considered > a problem of overloaded functions. > > One backward compatible solution is to implement overloading in scriptfu: >
[Gimp-developer] Discuss backward compatibility for multilayer changes to v3 PDB API
The v3 PDB API has changes for multilayer capability. For example this signature change: gimp-edit-copy(drawable) => gimp-edit-copy(drawableArray). This breaks some scripts in the GIMP repository and some third party plugins. To provide backward compatibility means allow existing scripts to work for a defined period. (say from 2.99 until 3.1). That allows users time to adjust their scripts. If we don't provide backward compatibility, it is a logistics problem: third party script authors must prepare an updated copy of their scripts, and change over immediately when they change from 2.10 to 3.0. Some scripts in GIMP 2.99 are broken now since the API was changed but scripts were not updated. If we provide backward compatibility, the GIMP developers can fix the scripts in the repository at their leisure. Because the name has stayed the same but the signature changed, to provide backward compatibility could be considered a problem of overloaded functions. One backward compatible solution is to implement overloading in scriptfu: whenever calling a PDB procedure, examine the actual arguments: if an arg is a single drawable, convert to a drawable array. (You could also do the same in GimpFu v3, if any.) An easier solution is to revert the signature change. Instead add a new PDB procedure gimp-edit-copy-multiple(drawableArray). Also redefine the body of gimp-edit-copy(drawable) to convert to an array and call the core function taking drawableArray. In other words, the old gimp-edit-copy(drawable) becomes a 'convenience' procedure for the more generic gimp-edit-copy-multiple(drawableArray.) You could also think of it as a "compatibility" procedure and warn that it is deprecated. Then if you don't want the PDB full of convenience/compatibility procedures, you could obsolete the procedure later (at say v3.1). You could also argue that the original meaning of gimp-edit-copy is more natural. Few script authors are even thinking about multiple layers. Relation to issues on ScriptFu: This is issue #6026. Some other backward compatiblity issues are dealt with by MR 403, but not this one. A fix to scriptfu for #5402 is also necessary, but is not 'for backward compatibililty.' Some have suggested that ScriptFu could use GObject Introspection (using say Guile-GI) in which case all scripts would need to be rewritten to use GI at least to deal with the broken PDB calls. Some hard-core lisp programmer would also need to step forward to integrate Guile-GI (or some other) with ScriptFu. ___ 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
