No description
8bb79dc671
While doing this, I could find a lot of problems in the algorithm: 1. It looks like the original intent (from GUI and code) is that you set hue and saturation but not really the intended lightness, rather its increase or decrease, relatively to every pixel current lightness. I.e. that every pixel will be set to the selected hue and saturation, and only the lightness will change. The "lightness" field is therefore a relative value (pixel per pixel). The first problem is that instead of lightness, we compute the luminance, which is related but different and set this in the lightness field. 2. The second issue is that we were using gimp_hsl_to_rgb() which after testing (because its documentation doesn't give any TRC/space info at all) looks like it computes a color from HSL to non-linear RGB of the same space. Yet we were outputting to a linear RGB space. So we compute the wrong values. On the other hand, because of the first problem, I realize (after testing) that it makes our render closer to the intended render by chance (at least when the TRC is sRGB's). It's still wrong, but if we were to change the output to "R'G'B'A float" instead, the render would be much darker. In both cases, it's wrong anyway. I would not say that the 2 problems are canceling each others, but they are making the final result somewhat OK. 3. Ideally we should be using babl to convert colors, and this is the best way to actually implement the original filter intent. Unfortunately so far, doing this is much slower (though I save a lot of time by moving out of the samples loop and processing data in chunks, it's still slower than the current, nearly instant, implementation). 4. Because of all previous implementation irregularities, the render is different depending on the actual image space. I.e. that the exact same image filtered through Colorize with the exact same operation parameters will render differently. I would need to test further, and maybe it's normal since HSL is also space-dependant (and that's where we work on in this operation), but I'm wondering if the result should not be independant of the working space. 5. I implemented our own prepare() method because the one in GimpOperationPointFilter parent seems to allow other input or output models. Even though in all my tests, it was always linear RGB (which is what we want here), let's make sure by having a custom prepare() method explicitly setting these. It's also the opportunity to create some babl fishes. In any case, I'm leaving the code as-is for now, because it's how this operation has been since forever (at least for as long as I was around) and I don't think it's the right idea to change it on a whim. This raises even more the concern of versionning GEGL operation, which we have been discussing with pippin on IRC lately, because if ever we want to change this one, now that operations are not just applied, but possibly non-destructively recreated at load, we need to make sure that we recreate the render expected at the time of creation of a XCF while allowing us to have the filters improving when needed. |
||
|---|---|---|
| .gitlab | ||
| .vscode | ||
| app | ||
| app-tools | ||
| build | ||
| cursors | ||
| data | ||
| desktop | ||
| devel-docs | ||
| docs | ||
| etc | ||
| extensions | ||
| icons | ||
| libgimp | ||
| libgimpbase | ||
| libgimpcolor | ||
| libgimpconfig | ||
| libgimpmath | ||
| libgimpmodule | ||
| libgimpthumb | ||
| libgimpwidgets | ||
| menus | ||
| modules | ||
| pdb | ||
| plug-ins | ||
| po | ||
| po-libgimp | ||
| po-plug-ins | ||
| po-python | ||
| po-script-fu | ||
| po-tags | ||
| po-tips | ||
| po-windows-installer | ||
| themes | ||
| tools | ||
| .clang-format | ||
| .dir-locals.el | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .kateconfig | ||
| AUTHORS | ||
| authors.dtd | ||
| authors.xml | ||
| authors.xsl | ||
| authors4gimp-web.xsl | ||
| ChangeLog.pre-1-0 | ||
| ChangeLog.pre-1-2 | ||
| ChangeLog.pre-2-0 | ||
| ChangeLog.pre-2-2 | ||
| ChangeLog.pre-2-4 | ||
| ChangeLog.pre-2-6 | ||
| ChangeLog.pre-git | ||
| COPYING | ||
| gimp.doap | ||
| INSTALL.in | ||
| LICENSE | ||
| MAINTAINERS | ||
| meson.build | ||
| meson_dist_script.sh | ||
| meson_options.txt | ||
| NEWS | ||
| NEWS.pre-2-0 | ||
| NEWS.pre-2-2 | ||
| NEWS.pre-2-4 | ||
| NEWS.pre-2-6 | ||
| NEWS.pre-2-8 | ||
| NEWS.pre-2-10 | ||
| README | ||
| README.i18n | ||
------------------------------
GNU Image Manipulation Program
2.99 Development Branch
------------------------------
This is an unstable development release, an intermediate state on the
way to the next stable release: GIMP 3.0. GIMP 2.99 may or may not do
what you expect. Save your work early and often. If you want a stable
version, please use GIMP 2.10 instead.
If you think you found a bug in this version, please make sure that it
hasn't been reported earlier and that it is not just new stuff that is
still being worked on and obviously not quite finished yet.
If you want to hack on GIMP, please read the file devel-docs/README.md.
For detailed installation instructions, see the file INSTALL.
1. Web Resources
================
GIMP's home page is at:
https://www.gimp.org/
Please be sure to visit this site for information, documentation,
tutorials, news, etc. All things GIMP-ish are available from there.
The latest version of GIMP can be found at:
https://www.gimp.org/downloads/
We also have a website dedicated to documentation at:
https://docs.gimp.org/
2. Contributing
===============
GIMP source code can be found at:
https://gitlab.gnome.org/GNOME/gimp/
Resources for contributors:
https://developer.gimp.org/
In particular, you may want to look in the "Core Development" section. Some
articles of particular interest for newcomers could be:
* Setting up your developer environment: https://developer.gimp.org/core/setup/
* GIMP Coding Style: https://developer.gimp.org/core/coding_style/
* Submit your first patch: https://developer.gimp.org/core/submit-patch/
3. Discussion Channels
======================
We have several discussion channels dedicated to GIMP user and
development discussion. There is more info at:
https://www.gimp.org/discuss.html
For the real junkies, there are IRC channels (e.g. #gimp or #gimp-user)
devoted to GIMP on GIMPNet (a private free software oriented network).
Many of the developers hang out there. Some of the GIMPNet servers are:
irc.gimp.org:6667
irc.us.gimp.org:6667
irc.eu.gimp.org:6667
More discussion channels, such as forums, will be listed on the above
"discuss" page when they are moderated by a team member.
Links to archives of former discussion methods (e.g. mailing lists) are
also included in that page.
4. Customizing
==============
The look of GIMP's interface can be customized like any other GTK+ app
by editing files in `${XDG_CONFIG_HOME}/gtk-3.0/` (settings.ini and
gtk.css in particular) or by using "themes" (ready-made customizations).
Additionally, GIMP reads `${XDG_CONFIG_HOME}/GIMP/2.99/gimp.css` so you
can have settings that only apply to GIMP.
You can also manually change the keybindings to any of your choice by
editing: `${XDG_CONFIG_HOME}/GIMP/2.99/shortcutsrc`.
Have fun,
Spencer Kimball
Peter Mattis
Federico Mena
Manish Singh
Sven Neumann
Michael Natterer
Dave Neary
Martin Nordholts
Jehan