Re: [Gimp-developer] [Gimp-user] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors
On 2/4/21 11:27 PM, Alexandre Prokoudine via gimp-user-list wrote: On Fri, Feb 5, 2021 at 3:00 AM Elle Stone wrote: 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. Two years ago we had three active developers hacking on GIMP like there was no tomorrow. We lost one of them entirely, it seems, and another one is mostly preoccupied with family business, so we are down to one active developer and a few new active contributors. We are also approaching the end of very long and tiresome work on refactoring which is not done yet. Also, a lot of time of that one active developer was spent figuring out ways to make development of GIMP sustainable (no details at this point in time, sorry). So yes, there are several critical areas where help is needed. Color management is clearly one of them. I guess if you adjust your expectations accordingly, you will see that there is no acting in bad faith here. Alexandre, I'm not sure why you felt obligated to introduce the idea of "acting in bad faith". It has not escaped my notice that various developers have cut back or ceased altogether from participating in GIMP development. I'm not even completely unaware of some of the reasons. Life happens, sometimes good, sometimes not good. Speaking for myself, I knew two years ago that I had a limited timeframe in which to hopefully help bring GIMP color management to the state of being reliable for color spaces other than sRGB. My family is dealing with some serious problems, has been for a long time now and will be for the foreseeable future. It's good to hear that someone on the team is trying to figure out how to make GIMP development sustainable. Hopefully that effort includes figuring out how to prioritize goals based on the editing needs of potential and actual users. To the members of the GIMP team who've worked with me over the years on various color-management/color-science topics - you know who you are, so I won't name any names - you went out of your way to help with my coding efforts and you made me feel like a part of the team - that meant a lot. Thank you. Speaking of "thank you", Michael Schumacher's "Concepts: Color Science" tag will be a big help to whichever current or future devs turn their attention to making GIMP finally be fully and reliably color-managed. One of the first things I did when starting to work on GIMP color management, was to compile a list for all open and closed GIMP bug reports having to do with color management, then read through and categorize all the bugs, to get an idea of what was already done, what was left to do, and most importantly to figure out what concerns motivated the users who filed the bug reports. A "Concepts: Color Science" tag would have been a big help. GIMP is important in the free-libre universe of image-editing programs. But without good color management GIMP is seriously flawed as a professional-level editing program. Best wishes to GIMP team members past, present, and future. Elle ___ 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] [Gimp-user] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors
On 2/4/21 7:14 PM, Michael Schumacher via gimp-user-list wrote: On February 5, 2021 12:59:50 AM GMT+01:00, Elle Stone wrote: 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. You make it sound like introducing this tag was a wrong decision. As I introduced it as a way to group thhese issues together, did I do something wrong there? Of course you didn't do anything wrong. It's an excellent tag to let people know what the topic is. It's been stated over and over again by a particular GIMP dev that GIMP development works best if people do what they are interested in doing. The question is which current GIMP devs other than myself have an *interest* in dealing bugs tagged with "Concept: Color Science"? It would be great if you could find the time to go through the links I provided in my post and add the tag as appropriate to any relevant bug reports that don't yet have the tag. Someday when GIMP has found another developer with an interest in color management and color science, that person will find the "Concepts: Color Science" tag very useful. Best, Elle ___ 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] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors
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, Elle Stone -- https://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] Please review my patch
Speaking of patches that need to be committed, here's a bug that's had a patch attached to it for over a year: https://gitlab.gnome.org/GNOME/gimp/-/issues/3471 My patch for #3471 does work and should be committed - the current code is clearly wrong - luma lighten and luma darken blend modes have been giving wrong results for a very long time. On 2/1/21 1:55 PM, Elle Stone wrote: My last comment in https://gitlab.gnome.org/GNOME/gimp/-/issues/2933 is: "Could someone please review this patch? It works. . . . This is a year old bug that could be fixed if someone would just commit the code. The corresponding bug in GEGL hue-chroma has been fixed - maybe we could get this fixed also in GIMP? Maybe even in GIMP-2.10?" #endquote Seven months later still nobody has reviewed the patch. A similar bug report, almost certainly the exact same bug - can't see how it could be anything else - was filed recently: https://gitlab.gnome.org/GNOME/gimp/-/issues/6308 to which bug report a request for "Additional Diagnostics" was attached. The requested "Diagnostics" were available 8 months ago in bug #2933. It's a matter of precision. The "EPSILON" value used in the layer blend code is too small to eliminate unavoidable rounding errors in the LCh Chroma code. I attached an updated patch to the new bug report. The update doesn't change the actual code that fixes the problem - it just allows the patch to be applied to the affected layer blend file given other recent changes to the file. I can guess the response from other devs as to why nobody has taken the time to review my patch: Other priorities, too few developers, too much to do, nobody else has color management or color science as a top priority. I do understand the problem of too few devs, but if one of the GIMP devs could take it upon themselves to finally get around to checking my patch, then three bug reports could be closed: the two mentioned above and also https://gitlab.gnome.org/GNOME/gimp/-/issues/2934 - leastways I'm pretty sure the latter bug is also fixed - none of these three bugs affect the already-patched version of GIMP that I use for editing. I had totally forgotten about bugs #2933 and #2934 (which I filed a year ago) until bug #6308 was filed. There's nothing else I can do about these bugs. I don't have - and don't want - commit rights to GIMP code. Some other GIMP dev needs to actually check the patch and decide it works and then apply it. Regards, Elle -- https://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
[Gimp-developer] Please review my patch
My last comment in https://gitlab.gnome.org/GNOME/gimp/-/issues/2933 is: "Could someone please review this patch? It works. . . . This is a year old bug that could be fixed if someone would just commit the code. The corresponding bug in GEGL hue-chroma has been fixed - maybe we could get this fixed also in GIMP? Maybe even in GIMP-2.10?" #endquote Seven months later still nobody has reviewed the patch. A similar bug report, almost certainly the exact same bug - can't see how it could be anything else - was filed recently: https://gitlab.gnome.org/GNOME/gimp/-/issues/6308 to which bug report a request for "Additional Diagnostics" was attached. The requested "Diagnostics" were available 8 months ago in bug #2933. It's a matter of precision. The "EPSILON" value used in the layer blend code is too small to eliminate unavoidable rounding errors in the LCh Chroma code. I attached an updated patch to the new bug report. The update doesn't change the actual code that fixes the problem - it just allows the patch to be applied to the affected layer blend file given other recent changes to the file. I can guess the response from other devs as to why nobody has taken the time to review my patch: Other priorities, too few developers, too much to do, nobody else has color management or color science as a top priority. I do understand the problem of too few devs, but if one of the GIMP devs could take it upon themselves to finally get around to checking my patch, then three bug reports could be closed: the two mentioned above and also https://gitlab.gnome.org/GNOME/gimp/-/issues/2934 - leastways I'm pretty sure the latter bug is also fixed - none of these three bugs affect the already-patched version of GIMP that I use for editing. I had totally forgotten about bugs #2933 and #2934 (which I filed a year ago) until bug #6308 was filed. There's nothing else I can do about these bugs. I don't have - and don't want - commit rights to GIMP code. Some other GIMP dev needs to actually check the patch and decide it works and then apply it. Regards, Elle -- https://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] new version
On 11/15/20 11:12 AM, Paka wrote: You can install a Gimp plugin - I prefer nufraw - which can import raw files (.arw too) into Gimp and there is darktable and rawtherapee and PhotoFlow. One consideration, depending on your anticipated workflow: darktable, RawTherapee, and PhotoFlow allow to keep processing at 32-bit floating point from raw processing to opening in GIMP. Last I checked (long time ago) nufraw only output at 16-bit integer. ___ 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] Color space conversions seems to change PCS as well
On 10/24/20 5:43 AM, marc...@seznam.cz wrote: Now, you are right that there's one inconsistency, gimp color picker's xyY is not the same as to what is being pushed to the operation. I've got the same color picker result as you have. Well, actually everything I said was right :) . Which means the discrepancies between GIMP's xyY values for sRGB reddest red and what you got at the command line still needs to be accounted for. I also reached out on the get issues for gimp and it might have been a known issue: https://gitlab.gnome.org/GNOME/gimp/-/issues/5805 Checking the referenced issue, exactly as I said, there's an assign where there should be a convert. To repeat, the discrepancies between GIMP's xyY values for sRGB reddest red and what you got at the command line still needs to be accounted for. This is a separate error from the "assign" instead of "convert" issue. Pippin - do you have any idea what caused the discrepancies in the reported xyY values for sRGB reddest red? Is it a problem in babl or GEGL? So if changing the rendering intent does make even a small difference I tested that again and there's no difference at all between perceptual and relative colorimetric. That's good! But I tried converting with saturation and absolute colorimetric and gimp stdouts that those conversions seem to be not implemented. babl hasn't implemented code for working with LUT profiles. Also matrix profiles don't have saturation intent tables, just as they don't have perceptual intent tables. And V4 profile processing always uses relative colorimetric for conversions between RGB matrix profiles regardless of any specified intent. Which is why any differences in results (other than "not supported" messages) from specifying different intents would have indicated a problem "somewhere". Elle ___ 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] Color space conversions seems to change PCS as well
On 10/23/20 6:17 AM, JonnyRobbie via gimp-developer-list wrote: When first opened, the image is in Built-in sRGB and the top row is pure rgb, that is 255,0,0; 0,255,0; 0,0,255. And when running my small gegl operation, I get this stdout in CIExyY color space: Input pixels x=0.653898, y=0.321709, Y=0.222488 The xyY values that GIMP *does* produce - and GEGL/babl from the command line *should* produce - for sRGB "reddest red" are these: x=0.648438 y=0.330867 Y=0.222488 So something seems wrong either in your code or in how GEGL/babl handles your input, even before you make the conversion from sRGB to ProPhotoRGB. Which seems roughly correct (though not exactly comforming to the sRGB standard, which should be 0.64, 0.33, 0.2126 for the Red - that is also weird). In GIMP the sRGB color space (with its D65 illuminant) has been Bradford-adapted to D50 to produce the sRGB ICC profile, which is why there is a small difference between the sRGB color space values and the sRGB ICC profile values. As an aside, if/when babl/GEGL/GIMP ever extends ICC profile support to include iccMAX (which allows illuminants other than D50s), and/or provides support for OCIO color management in addition to ICC profile color management, then babl/GEGL/GIMP will have the ability to also work using D65 sRGB values. But these future possibilities aren't relevant to the results you are currently getting. Then I convert the image to ProPhoto RGB (for example) color space. Now the "pure" sRGB colors are no longer represented as pure values - but that is to be expected - that is how color spaces work. So far so good. The problem comes when I try to peep at the xyY values using my operation: Input pixels x=0.576892, y=0.363497, Y=0.144828 Input pixels x=0.356573, y=0.513024, Y=0.668290 Input pixels x=0.175974, y=0.085000, Y=0.083105 ... Those seem to differ as well, which is wrong as CIExyY color space is a profile connection space and the values there should be objective values not burdened by any device profile/working space. Yes, as you note the xyY values should be the same before and after a color space conversion between well-behaved RGB matrix working spaces, assuming the source/destination illuminants match, which in current GIMP/GEGL/babl code should always be the case. I was able to use GIMP to approximate your above results by following these steps: 1. For an sRGB image, fill with sRGB's reddest red. 2. Convert the image to ProPhotoRGB. 3. *Assign* the built-in sRGB color space to the newly-converted image, which changes the color from bright red to middle dullish orange. After following these steps, here are the resulting xyY values from sampling the image color using GIMP color picker tool (the eye-dropper in the toolbox, not the eye-dropper in the FG/BG tool): x=0.553973, y=0.386853, Y=0.189302 which values are close to what you are getting - for comparison, here are your values again: Input pixels x=0.576892, y=0.363497, Y=0.144828 So it looks like maybe, possibly: * There is some error - either in your code or in GEGL/babl code or maybe both, or possibly even in the particular ICC profiles you might be using - that's producing somewhat wrong xyY values in the first place. * Then there is some other error that's inserting an "assign" where there should be a "convert". (Rendering intents seem to have no significant change) Yes, in the case you are describing and b/where ecause GIMP nominally uses V4 ICC profile management (babl has taken over some of the ICC profile conversion tasks), using different rendering intents should make no difference at all to the results because: * Both the source and destination profiles are (should be) well-behaved ICC RGB matrix working spaces, hence only using relative colorimetric intent regardless of any specified intent. * The source and destination profiles have matching D50 white points and 0,0,0 black points, so using or not using black point compensation should make no difference at all. So if changing the rendering intent does make even a small difference, that suggests yet another problem, possibly in the GEGL/babl code, possibly even with one of the ICC profiles involved in the color space conversion. In case it might be relevant, which version of babl/GEGL/GIMP are you using, on which operating system? Also, which sRGB and ProPhotoRGB ICC profiles are you using - who was the profile provider? Best regards, Elle ___ 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] GIMP-2.99 terminal complaints: python3, not finding Gegl v0.4, exceptions/tracebacks, various plug-ins
On 9/5/19 9:11 AM, Øyvind Kolås wrote: At least there is problems related to python / gobject introspection not finding the Gegl-0.4.typelib, on my system that file is in $PREFIX/lib/x86_64-linux-gnu/girepository-1.0 and that path has to be added to the little documented GI_TYPELIB_PATH. Gobject-introspection seem to be refined for system installed libraries/scripts, but there are more hoops we have to run through for people that are building and installing in custom prefixes. Hi Pippin, and thanks! for the typelib hints. Sadly that didn't fix the terminal complaints, so maybe I'm still doing something wrong, or maybe more paths are needed, or maybe the code itself has issues. On Debian Sid in my GIMP-2.99 prefix, the babl/GEGL typelibs are here: $PREFIX/lib/x86_64-linux-gnu/girepository-1.0/ and the GIMP typelib is here: $PREFIX/lib/girepository-1.0 Unfortunately, setting up my prefix like this: PREFIX=$HOME/code-install/gimp299/install export SRC_DIR=/home/elle/code-build/gimp299/build export PATH=$PREFIX/bin:$PATH export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=$PREFIX/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/share/pkgconfig:$PKG_CONFIG_PATH export GI_TYPELIB_PATH=$PREFIX/lib/x86_64-linux-gnu/girepository-1.0:$PKG_CONFIG_PATH export GI_TYPELIB_PATH=$PREFIX/lib/girepository-1.0:$PKG_CONFIG_PATH export XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share:/usr/local/share/:/usr/share/" and then rebuilding/installing babl/GEGL/GIMP-2.99 from scratch, and then running GIMP-2.99, still results in typelib errors printed to the terminal (the other errors disappeared after updating GIMP yesterday, so not related to these remaining errors). Any ideas on what still needs to be changed? Did I set up the prefix correctly? Anything else needed? Maybe there's an issue in the plug-in code for the affected plug-ins? Maybe the python-related errors mean something needs to be added for python? Best, Elle Here's the terminal output on starting the rebuilt/installed babl/GEGL/GIMP-2.99 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/elle/code-install/gimp299/install/lib/gimp/2.99/plug-ins/spyro-plus/spyro-plus.py", line 20, in from gi.repository import Gimp File "/usr/lib/python3/dist-packages/gi/importer.py", line 140, in load_module raise ImportError(e) ImportError: Typelib file for namespace 'Gegl', version '0.4' not found GIMP-WARNING: gimp-2.99: gimp_wire_read(): error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/elle/code-install/gimp299/install/lib/gimp/2.99/plug-ins/py-slice/py-slice.py", line 30, in from gi.repository import Gimp File "/usr/lib/python3/dist-packages/gi/importer.py", line 140, in load_module raise ImportError(e) ImportError: Typelib file for namespace 'Gegl', version '0.4' not found GIMP-WARNING: gimp-2.99: gimp_wire_read(): error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call
[Gimp-developer] GIMP-2.99 terminal complaints: python3, not finding Gegl v0.4, exceptions/tracebacks, various plug-ins
I just updated and recompiled babl/GEGL/GIMP-2.99 (through GIMP commit commit 7019eaa56bcd9fc77f215e36c280bf6daae641e5), with no errors during the build, but with a lot of terminal complaints upon starting GIMP. I'm guessing the code is still in a state of flux from all the recent activity regarding plug-ins, so filing a bug report seems a bit silly. GIMP did start and run without any problems or significant further terminal complaints. In case it's helpful, here's the terminal output: # First, several screen's worth of these error messages: ### _gimp_gp_param_def_to_param_spec: GParamSpec type 'GimpParamImageID' is not handled GIMP-CRITICAL: gimp_procedure_add_return_value: assertion 'G_IS_PARAM_SPEC (pspec)' failed _gimp_gp_param_def_to_param_spec: GParamSpec type 'GimpParamImageID' is not handled GIMP-CRITICAL: gimp_procedure_add_argument: assertion 'G_IS_PARAM_SPEC (pspec)' failed _gimp_gp_param_def_to_param_spec: GParamSpec type 'GimpParamDrawableID' is not handled GIMP-CRITICAL: gimp_procedure_add_argument: assertion 'G_IS_PARAM_SPEC (pspec)' failed # Followed by many complaints about python3, not finding Gegl v0.4, exceptions/tracebacks, and various plug-ins: ### Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/elle/code-install/gimp299/install/lib/gimp/2.99/plug-ins/spyro-plus/spyro-plus.py", line 20, in from gi.repository import Gimp File "/usr/lib/python3/dist-packages/gi/importer.py", line 140, in load_module raise ImportError(e) ImportError: Typelib file for namespace 'Gegl', version '0.4' not found GIMP-WARNING: gimp-2.99: gimp_wire_read(): error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/elle/code-install/gimp299/install/lib/gimp/2.99/plug-ins/py-slice/py-slice.py", line 30, in from gi.repository import Gimp File "/usr/lib/python3/dist-packages/gi/importer.py", line 140, in load_module raise ImportError(e) ImportError: Typelib file for namespace 'Gegl', version '0.4' not found GIMP-WARNING: gimp-2.99: gimp_wire_read(): error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/elle/code-install/gimp299/install/lib/gimp/2.99/plug-ins/palette-to-gradient/palette-to-gradient.py", line 18, in from gi.repository import Gimp File "/usr/lib/python3/dist-packages/gi/importer.py", line 140, in load_module raise ImportError(e) ImportError: Typelib file for namespace 'Gegl', version '0.4' not found GIMP-WARNING: gimp-2.99: gimp_wire_read(): error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gi/importer.py", line 138, in load_module introspection_module = get_introspection_module(namespace) File "/usr/lib/python3/dist-packages/gi/module.py", line 265, in get_introspection_module module = IntrospectionModule(namespace, version) File "/usr/lib/python3/dist-packages/gi/module.py", line 117, in __init__ repository.require(namespace, version) gi.RepositoryError: Typelib file for namespace 'Gegl', version '0.4' not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File
Re: [Gimp-developer] GIMP build: XDG_DATA_DIRS causing "Unrecognized image file format"
On 9/3/19 3:38 PM, Liam R. E. Quin wrote: On Tue, 2019-09-03 at 15:10 -0400, Elle Stone wrote: Couldn't find include 'Babl-0.1.gir' (search path: '['gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0']') [223/750] Generating module_common_gpl3.c with a meson_exe.py custom command. XDG_DATA_DIRS is used to find this. So, i think what matters is having XDG_DATA_DIRS set, but also the order of the entries within it when it is set. You need $prefix first i think. Thanks! So for current (as of last week) Debian Sid and current babl/GEGL/GIMP-2.99 (as of this morning), XDG_DATA_DIRS really does need to be set. But for Debian Testing, it seems XDG_DATA_DIRS shouldn't be set. I wonder what has changed between Debian Testing and Sid. Anyone know what an XDG_DATA_DIRS actually is? Also, what is this "gir" thing that GEGL was looking for? Elle ___ 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] GIMP build: XDG_DATA_DIRS causing "Unrecognized image file format"
On 9/3/19 11:59 AM, Akkana Peck wrote: Does setting XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share:/usr/local/share/:/usr/share/" actually work for you, and you don't see the "Unrecognized image file format" problem any more? Well, it did work exactly as I posted. FWIW, just now I tried rebuilding GIMP-2.99 from scratch, starting from an empty install folder, but with the line 'XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share:/usr/local/share/:/usr/share/"' commented out. But the build failed at GEGL (terminal output is below). Whether this failure to build with the XDG line commented out is coincidence or not, I just don't know, haven't yet taken the time to figure it out. What I do know is that building babl/GEGL/GIMP is getting increasingly complicated. It would be nice if the developers who are writing all this new code for GIMP-2.99 could provide up-to-date guidelines for building all this new code :) but I guess "how to build" varies a lot from one system (and day) to the next. I do vaguely remember the issue you mentioned with not finding the image file formats. That was on Debian, but not the current version of Debian Sid. There was another issue? The same issue? - sorry, I don't remember - that I encountered recently on Debian Sid, where the advice from Hacking GIMP was contrary to what actually worked, though the Hacking GIMP advice had worked previously. In case anyone has an idea what went wrong, here's the terminal output for the failed GEGL build: elle@debian:~/code-build/gimp299/build/gegl/build$ ninja install [214/750] Generating Gegl-0.4.gir with a custom command. FAILED: gegl/Gegl-0.4.gir /usr/bin/g-ir-scanner -pthread -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include --no-libtool --namespace=Gegl --nsversion=0.4 --warn-all --output gegl/Gegl-0.4.gir --c-include=gegl.h -I/media/data1/code-build/gimp299/build/gegl/gegl -I/media/data1/code-build/gimp299/build/gegl/build/gegl -I./. -I../. -I./gegl/. -I../gegl/. -I./gegl/buffer -I../gegl/buffer -I./gegl/graph -I../gegl/graph -I./gegl/module -I../gegl/module -I./gegl/opencl -I../gegl/opencl -I./gegl/operation -I../gegl/operation -I./gegl/process -I../gegl/process -I./gegl/property-types -I../gegl/property-types --filelist=/media/data1/code-build/gimp299/build/gegl/build/gegl/2cd4258@@gegl-0.4@sha/Gegl_0.4_gir_filelist --include=GLib-2.0 --include=GObject-2.0 --include=Babl-0.1 --symbol-prefix=gegl --identifier-prefix=Gegl --cflags-begin -DHAVE_CONFIG_H -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -Wno-deprecated-declarations -mfpmath=sse -mmmx -msse -msse2 -msse4.1 -I./. -I../. -I./gegl/. -I../gegl/. -I./gegl/buffer -I../gegl/buffer -I./gegl/graph -I../gegl/graph -I./gegl/module -I../gegl/module -I./gegl/opencl -I../gegl/opencl -I./gegl/operation -I../gegl/operation -I./gegl/process -I../gegl/process -I./gegl/property-types -I../gegl/property-types -I/home/elle/code-install/gimp299/install/include/babl-0.1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 --cflags-end --library gegl-0.4 -L/media/data1/code-build/gimp299/build/gegl/build/gegl -L/home/elle/code-install/gimp299/install/lib/x86_64-linux-gnu -L/home/elle/code-install/gimp299/install/lib/x86_64-linux-gnu --extra-library=babl-0.1 --extra-library=glib-2.0 --extra-library=gio-2.0 --extra-library=gobject-2.0 --extra-library=m --extra-library=gmodule-2.0 Couldn't find include 'Babl-0.1.gir' (search path: '['gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0']') [223/750] Generating module_common_gpl3.c with a meson_exe.py custom command. ninja: build stopped: subcommand failed. ___ 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] help compiling babl
On 8/22/19 5:43 PM, Akkana Peck wrote: I had a lot of trouble adjusting my build scripts for babl's meson build. So once I got it working, I ended up rewriting the GIMP wiki build instructions to reflect what worked for me. https://wiki.gimp.org/wiki/Hacking:Building Hi Akkana, Thanks! for updating the wiki. In case it helps, the paths for setting up the prefix vary from one distribution to the next, for example are very different for Debian Sid compared to Gentoo. In a fresh install of Debian Sid, after a lot of trial and error I finally managed to build babl (meson)/GEGL (meson)/GIMP-2.10 using these lines to set up the prefix: PREFIX=$HOME/code-install/gimp210/install export SRC_DIR=/home/elle/code-build/gimp210/build export PATH=$PREFIX/bin:$PATH export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=$PREFIX/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/share/pkgconfig:$PKG_CONFIG_PATH export XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share:/usr/local/share/:/usr/share/" Notice on Debian Sid the "64-bit" folder where GEGL puts its ".so" files is "$PREFIX/lib/x86_64-linux-gnu". On Gentoo, the equivalent folder is "$PREFIX/lib64". These lines worked for setting up the prefix in Gentoo: PREFIX=$HOME/code-install/gimp210/install export SRC_DIR=/hdd/data1/code-build/gimp210/build export PATH=$PREFIX/bin:$PATH export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=$PREFIX/lib64:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/lib64/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/install/share/pkgconfig:$PKG_CONFIG_PATH export GIO_EXTRA_MODULES=/usr/lib/gio/modules #above line probably isn't needed as I'm no longer build glib in the prefix export XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share" Best, Elle ___ 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] Questions about the histogram
On 08/12/2019 10:07 AM, Elle Stone wrote: On approximately 08/11/2019, Steve Pricks wrote: (text below copied from Nabble) However, I have not seen buttons like these in any other image editing software, neither commercial nor free/libre (not even in RT with its technology filled GUI). On 08/11/2019 04:34 PM, Elle Stone wrote: I'll try to continue responding to your post tomorrow or hopefully later today. Continuing on where I left off, To get some input from other relevant software I did some checks: Lightroom 8.3.1: Article [1] describes how Lightroom handles this in its Develop module: it works with a profile of ProPhotoRGB gamut and whitepoint. Internally it computes with a linear TRC, but the histogram in the Develop module uses a gamma ~2.21 sRGB TRC (they named it MelissaRGB profile). This sounds similar to GIMPs behaviour, but with a greater color space. (I don't want to revive the old discussions here). I ran a test by converting images to ProPhotoRGB and clicking the "perceptual" button which shows the histogram using the sRGB TRC. It's visually almost equal to LR's histogram in the Develop module and Library module. Lightroom is somewhat similar to GIMP, in that some (all?) Lightroom operations are done "under the hood" in linear RGB. But apparently Lightroom "lies" to you about the TRC encoding, and never let's you see the linearly encoded histogram, I'm guessing because their intended audience is used to using perceptual histograms. I think Lightroom is pretty funny given that for years and years PhotoShop users in various forums (eg Luminous Landscape) ridiculed anyone editing in linear RGB color spaces. But seeing the actual linear histograms is sometimes helpful and necessary, for example if you want a physically meaningful "ev/stop-based" presentation at the information captured by your digital camera. Take a look at software like the old Rawnalyze (http://dave-anderson-photo.com/blog/2010/08/23/gabor-rawnalyze-author-rip/ - closed source Windows software, runs under WINE - an example screenshot is in Section A of this article: https://ninedegreesbelow.com/bug-reports/ufraw-highlights.html). Also, if you have access to Mac, or don't mind reading through the documentation, take a look at RPP's histograms (https://www.raw-photo-processor.com/RPP/Overview.html, https://www.rawdigger.com/usermanual) Also consider dealing with HDR images. I don't mean tone-mapped images, I mean actual linearly encoded HDR images, which today's camera raw files many times actually already are HDR images after an appropriate middle gray point is set. GIMP's floating point processing already can be used for HDR images, and histograms for such images make no sense at all if presented (or manipulated) using perceptually uniform RGB. Photoshop CC: Histogram view and histogram in Camera Raw Filter look close to the perceptual view. Darktable 2.6.0: No match at all. It shows almost nothing where the other histograms have massive peaks. Darktable 2.7.0+1612~g9e212dc9d-dirty: Shows nothing at all. Krita 4.2.5: Looks like the perceptual view. RawTherapee 5.6.1: Looks like the perceptual view. DxO Optics 11: Looks like the perceptual view. As it seems, the perceptual view is common. Elles lines read as perceptual uniformity has benefits or is required - why? For Krita and PhotoShop, and also my "CCE" version of GIMP, after opening an image in any RGB color space, the histogram always and only reflects the color space's actual TRC. So for these softwares, if the embedded ICC profile has a linear TRC (gamma=1.0), then you get a linear histogram. And if the ICC profile has the sRGB TRC, you get the sRGB-encoded histogram (almost perceptually uniform). And if the ICC profile has the gamma=1.8 TRC, well, you get the point. As an exercise to understanding how GIMP histogram buttons work: Open an image in the regular sRGB color space in my CCE version of GIMP or in Krita or PhotoShop. Look at the histogram - it will match GIMP's perceptual histogram. Then convert the image to one of the linear gamma versions of sRGB included in my github ICC profile collection (I know you already have the link to these profiles), and watch the histogram change to match GIMP's linear histogram. I think one crucial step to finish the work while avoiding further confusion about mysterious buttons is to do some user research among the aforementioned user groups and then do decide whether and how these buttons should stay in the GUI. Perhaps different histogram views as outlined in [2] could be a solution. The aforementioned user groups aren't using GIMP, and so what works for the aforementioned user groups is only tangentially relevant to what will work for GIMP users. GIMP histograms need improvement in two very different areas: 1. Ability to zoom in on a portion of the histogram to more precisely view and set points for ma
Re: [Gimp-developer] help compiling babl
On 08/12/2019 03:38 PM, Ken Moffat via gimp-developer-list wrote:
On Mon, Aug 12, 2019 at 02:33:42PM -0400, Elle Stone wrote:
On 08/12/2019 01:38 PM, Alexandre Prokoudine via gimp-developer-list wrote:
Hello,
You should be using the Meson build system now.
In case it helps anyone, here are the lines I've been using with meson to
build babl:
cd $SRC_DIR/babl
git status
rm -r build
git checkout build
cd build
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" meson --prefix=$PREFIX ..
ninja install
Here are some questions about meson:
1. Any suggestions to modify my lines?
Hi Ken, and thanks much! for the very helpful information.
Adding '-Dbuildtype=release' to a meson package will turn off debug
assertions, if any (e.g. mesa) and (usually) use -O3 (ISTR that at
least pango uses -O2 for a release build).
2. Do the CFLAGS lines actually do anything when using meson?
Do a verbose build using 'ninja -v' to see what flags and defines
are used. I usually do separate steps for 'ninja' and 'ninja
install', but whatever works for you. Verbose builds will produce a
_lot_ more output, teeing it to a log so you can read it afterwards
helps (but I'm sure you know that).
3. How do I tell meson to use "something" equivalent to the following "make"
lines?
./autogen.sh --prefix=$PREFIX --enable-avx2=false --enable-mmx=no
--enable-sse=no --enable-sse2=no --enable-sse3=no --enable-sse4_1=no
--enable-f16c=no --enable-altivec=no --disable-docs
I very much doubt you are on ppc/powerpc, so altivec cannot be used.
In general, meson uses defines (-Dsomething=value, rather like
cmake) for things which are not covered by --prefix= --sysconfdir=.
To see the options for a particular package, look in the
meson_options.txt file. That might have an option to disable docs,
or it might even be automatic if the deps are missing.
With -march=native I would tend to let gcc sort out sse and similar
options. I'm assuming you are on x86_64.
Regarding my "make" options for babl, I disabled anything to do with CPU
code because at one point the only thing that code in babl did was make
the TRC transforms faster, and I was building babl for my "CCE" version
of GIMP, which has no TRC transforms. So I just disabled any and all
options related to the CPU (and for good measure ripped the relevant
code out of the CCE version of babl).
I guess I should check to see what the babl CPU code does today. But if
the code is hard-coded to the sRGB TRC, it still won't work with the
somewhat modified version of GIMP I build for actual editing (as opposed
to the versions I build for keeping up with and testing the default GIMP
code).
The gcc manual gives some options (for X86) about what you can put
in CFLAGS|CXXFLAGS, see the -mfpath= section.
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
(That is for 9.2, probably the only big change from 9.1 is adding
znver2). And more generally, the -f options are linked from
.../gcc/Option-Index.html
Docs for the latest point release of each gcc version are at
https://gcc.gnu.org/onlinedocs/ if you are using an earlier major
version.
OTOH, if you have the (lots of) time needed to try playing with
these options, and scripts which you can run using 'time' (several
runs for each different build) then perhaps tuning out some of these
things might be worthwhile. I spent a lot of time in the past couple
of months doing whole-system builds with different flags (mostly for
slight hardening) and ended up concluding there was just too much
variation between runs to get much meaningful data on timing. And I
didn't have any runtime scripts for gimp-related actions.
I wasn't actually trying to optimize this or that using timings or
anything sophisticated, just relying on some flags that were posted to
the developer's list a long time ago in response to the general question
"how to make GIMP go faster". That was back maybe around 2015 or so -
there was other advice also, I wonder how much is still pertinent after
all this time.
I have no idea whether these flags actually did or still do make GIMP go
faster or not. But given the source of the recommendations - someone who
seems to know what they are doing - I was and still am inclined to keep
using the flags. Though given the many versions of gcc that have come
and gone in the meantime, maybe the flags no longer make any sense.
Updated general advice on cflags is very welcome! If it matters, my CPU
is an Intel Core i7-4790K.
ĸen
Ken, again, thank you so much! That meson stuff was/is very puzzling.
Next time I build babl I'll try to put your pointers to good use.
Best,
Elle
--
https://ninedegreesbelow.com
Color management and free/libre photography
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail
Re: [Gimp-developer] help compiling babl
On 08/12/2019 01:38 PM, Alexandre Prokoudine via gimp-developer-list wrote:
Hello,
You should be using the Meson build system now.
In case it helps anyone, here are the lines I've been using with meson
to build babl:
cd $SRC_DIR/babl
git status
rm -r build
git checkout build
cd build
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" meson --prefix=$PREFIX ..
ninja install
Here are some questions about meson:
1. Any suggestions to modify my lines?
2. Do the CFLAGS lines actually do anything when using meson?
3. How do I tell meson to use "something" equivalent to the following
"make" lines?
./autogen.sh --prefix=$PREFIX --enable-avx2=false --enable-mmx=no
--enable-sse=no --enable-sse2=no --enable-sse3=no --enable-sse4_1=no
--enable-f16c=no --enable-altivec=no --disable-docs
Alex
On Mon, Aug 12, 2019 at 8:36 PM Marco Ciampa via gimp-developer-list
wrote:
Hi devs, I have a prolem compiling babl...
from master git I do:
./configure
make
make: *** No rule to make target 'Makefile.am', needed by 'Makefile.in'. Stop.
but with a:
git checkout BABL_0_1_68
it works...
what's going on here?
TIA
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
GNU/Linux User #78271
FSFE fellow #364
___
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
--
https://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] Questions about the histogram
On 08/11/2019 04:34 PM, Elle Stone wrote: On 07/30/2019 09:07 AM, Elle Stone wrote: On approximately 08/11/2019, Steve Pricks wrote: (text below copied from Nabble) However, I have not seen buttons like these in any other image editing software, neither commercial nor free/libre (not even in RT with its technology filled GUI). An actually helpful evaluation of and suggestions for improving the histogram buttons does require a good understanding of how GIMP works "under the hood". * Many operations (eg Normal/Addition?Subtract/Multiply/Divide blend modes (and a few other blend modes), Gaussian and other blurs, down-scaling, Exposure, radiometrically meaningful Levels adjustments including white balancing, Channel mixing, conversions to Luminance black and white - the list goes on and on) *require* being done on linear RGB to avoid "gamma" artifacts and produce radiometrically correct results. * Many other operations are *designed* to work on perceptually uniform RGB, for which purpose GIMP uses the sRGB TRC instead of the more appropriate (imho) Lab "L" TRC. These operations include Luma conversions to black and white, plus various layer blend modes such as Soft Light/Hard Light/Screen/Burn/etc, plus no doubt a plethora of legacy operations and plug-ins. Either way, and unlike various other editing programs, GIMP does the appropriate transform between linear and perceptual encoding "under the hood" to produce correct results, with "correct" defined for each operation. This is one reason (not the only reason) for the two buttons (linear and perceptual) in GIMP-2.10. I'm assuming based on preliminary testing - and hopefully Pippin will correct me if I'm wrong - that the third button in GIMP-2.99 is to accomodate use cases such as opening a ProPhotoRGB image encoded using gamma=1.8 TRC, and wanting to produce results that match PhotoShop when the "linear" option is disabled in the PS Color Management settings. As an aside, please note: "linear" option in PS CM settings doesn't affect all 16-bit editing operations, and 32f editing in PS is handled somewhat differently than 16-bit integer editing. See this article and try the tests using PhotoShop at various bit depths: https://ninedegreesbelow.com/photography/test-for-linear-processing.html That's all I can write right now. Hope it helps. I'll try to continue responding to your post tomorrow or hopefully later today. Best, Elle ___ 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] Questions about the histogram
mpiled and uploaded to gitlab my "GIMP-CCE" version of babl/GEGL/GIMP, that uses the image's actual color space matrix to calculate all operations that use Y/XYZ/Lab/LCh/etc. I used a global variable to do this, which variable was available to all operations that needed it. In my CCE version of GIMP, all operations that *don't* involve a conversion to XYZ just operate on RGB channel values "blissfully unaware" of the image's actual color space. Which imho is exactly what *should* happen because, for example, "Multiply" and "Levels" don't need to know what color space the image is in. But conversions to Luminance and to LCh do need to know what color space the image is in. By comparison, in default GIMP-2.99 post-space-invasion, all operations that don't *specifically* request to use the image's actual RGB color space matrix, assume the sRGB color space matrix instead. So just about all operations, whether they actually uses Y/XYZ/Lab/LCh/etc or not, need to be tested and possibly recoded before the space invasion is complete. Personally I think this is a somewhat odd coding decision, because it means the number of "cases" to check for correct operation post-space-invasion is astronomical. And any slip of the coding can reintroduce errors. 2. The histogram's RGB luminance weights are calculated from GIMP's builtin sRGB profile, see gimprgb.h, lines 193-195. Will the space invasion project change this? This question needs to be answered twice. I'm not sure whether the GIMP-2.99 histogram RGB luminance display actually gives wrong results or not. I'd have to check and see. Because it's entirely possible that the histogram is calculated by first converting the image from its actual RGB matrix to the sRGB matrix, before displaying the Luminance histogram. If this is what's currently being done, then this is a case of "using sRGB as the PCS" about which you can find much verbiage spilled on this list a few years ago if you search Nabble archives of GIMP mailing lists. So ironically, *if* the babl/GEGL/GIMP code really is using "sRGB as PCS" for any given operation that requires a conversion to XYZ, then the very operations that one would expect to fail (operations that involve conversions from RGB to XYZ) pre-space-invasion actually might be giving correct results. You'd have to look at the actual code for each specific operation to see whether it's thrown in a conversion to sRGB before making the conversion to XYZ. Thank you for your answers. As some of the people on this list know, I have an ongoing problem with my wrists and hands that makes sustained typing difficult. Having typed out answers to Steve's questions, it will require an icepack and several hours of rest before I can type again with any degree of comfort. But I thought it was important to actually answer Steve's questions because they are very important questions. Hopefully what I've written sheds some light on the current state of the space invasion. Hopefully someone will come along "sooner rather than later" with better coding abilities than I have, and make the space invasion a priority. Once someone decides to work on finishing the space invasion, it will take a *lot* of testing to make sure everything is working properly with each new space invasion code change. Anyone who wants to help with testing the space invasion, it's a good idea to go ahead and compile my "GIMP-CCE" to use as a reference for "Is operation X working properly post-space-invason". If anyone is actually interested in helping with testing the space invasion, let me know and I'll upload to my github account a small code change required to allow "CCE" to read current GIMP XCF files. And I'll be happy to explain the details of actually using CCE to cross-check post-space-invasion editing results. Best regards, Elle Stone -- https://ninedegreesbelow.com Color management and free/libre photography Steve ___ 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] Building GIMP master fails because of missing gobject-introspection
On 07/29/2019 09:28 AM, Steve Pricks wrote: On 07/29/2019 12:17 AM Elle Stone wrote: I do have a question: Could someone please explain what introspection actually is or does? Introspection is a term from computer science. Introspection is a way to look at a given program and tell about its functions and data structures. This information is then used to access the program’s functions from another program (even in another programming language) or to create a documentation etc. Thanks! That's clear! As far as I know the GIMP developers use it to access GIMP’s functions from Python plug-ins, but they might tell you more about their intentions themselves. Best, Elle ___ 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] Building GIMP master fails because of missing gobject-introspection
On 07/29/2019 04:14 AM, Steve Pricks wrote: Hello, I was trying to build GIMP master (commit f74320d4dc5e92351001cd44c4380c95725eccd5). Configure failed with this message: checking for gobject-introspection... configure: error: gobject-introspection-1.0 is not installed Configure failed or did not finish! It also happened when I pass the parameter --enable-introspection=no Interestingly having the Debian package gobject-introspection (version 1.58) installed didn't have an effect. After installing the package libgirepository1.0-dev it works, but it seems that the handling of the parameter --enable-introspection=no is buggy (or if introspection is required, then it should not be possible to disable it). Steve I don't have an answer except that checking the latest commits introspection does now look to be required: https://gitlab.gnome.org/GNOME/gimp/commit/41d3b478a2899bf1e855f97d5d19784eeb9bd01f I do have a question: Could someone please explain what introspection actually is or does? And why it's now required for GIMP instead of optional? I've looked "introspection" up on the internet several times over the last few years - all the explanations I've seen just seem like a bunch of gibberish words all lined up into gibberish paragraphs. Elle ___ 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] Converting 8-bit integer color palettes to floating point
Hi All, It seems to me - I could be wrong - that it would be very easy to add a line to the palette files that specifies the babl format, perhaps even the babl format with space, that would allow, for example, user A to save 8-bit sRGB indexed image RGB channel values along with the Alpha channel values, and user B to save 32f LCh values with no Alpha channel information, and etc. And then add code that "decodes" the palette color entries according to the babl format. Yes? No? Best regards, Elle On 03/08/2019 04:44 PM, Elle Stone wrote: Hi All, In these two GIMP bug reports: * Support for high bit depth RGB (and LCH?) color palettes for painting https://gitlab.gnome.org/GNOME/gimp/issues/1328 * Add support for Swatchbooker's SBZ colour palette format https://gitlab.gnome.org/GNOME/gimp/issues/2011 are discussions regarding either *converting* GIMP code to use SwatchBooker for high bit depth color palettes, or else *keeping* GIMP GPL palette code (updated to use floating point), and also adding support for importing/exporting SwatchBooker color palettes. Here's the current git repository for SwatchBooker, maintained by Olivier Berten: https://github.com/olivierberten/SwatchBooker Adding support for importing/exporting SwatchBooker color palettes seems like a really good idea for reasons given by "Christoph S" in bug #2011. But converting all GIMP color palette code to use SwatchBooker maybe isn't such a good idea given the reality that maintainers of various free/libre projects do come and go as their lives place various demands on time and energy. Anyway, I did write some barebones working code to convert GIMP color palette code from 8-bit integer to floating point. Details and the patches are in bug #1328. My floating point palette code isn't finished. Well, it's sufficiently finished for my own needs. But I drastically simplified the palette code by removing everything except the core code for opening and saving a palette to/from a GPL file. Otherwise I'd still by trying to figure out which of the many the palette-related files/functions/variables does what. If the GIMP team reaches a consensus to *keep* GIMP's GPL palette code and just update it to be floating point (and of course add support for importing/exporting SwatchBooker assets) - instead of *replacing* GIMP's GPL palette code with SwatchBooker - then I'd go ahead and try to add back into my working patch the various non-core palette functions that I removed to make it easier to figure out the core palette code. Best regards, Elle ___ 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 -- https://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
[Gimp-developer] A possibly easier way to AnyRGB
Hi All, Currently GIMP uses hard-coded sRGB primaries for many operations, thereby producing wrong results when editing images in RGB color spaces other than sRGB. Also currently GIMP color pickers only pick colors, only allow dialing in colors, only show out of gamut indicators colors using sRGB. Well, it's ridiculous to be editing an image in ClayRGB (aka AdobeRGB) and be told a green color is out of gamut, when it's only out of gamut wrt sRGB. Based on testing the space invasion for GIMP-2.99, it seems fairly massive changes are required to implement "AnyRGB" one function at a time. But maybe there is an easier way to implement AnyRGB. *My current workaround for GIMP-2.10:* Currently I compile GIMP-2.10 in multiple prefixes, one prefix per RGB color space that I actually want to edit in. These prefixes are easy to set up: For GIMP, only two files need to be modified: * libgimpcolor/gimpcolorprofile.c * libgimpcolor/gimprgb.h For babl, only one file needs to be modified: * babl/babl-space.c If anyone wants to set up a ClayRGB prefix, patches can be downloaded here - required modifications for other ICC profiles should be obvious: https://ninedegreesbelow.com/files/GIMP-ClayRGB-prefix/GIMP-ClayRGB-prefix.zip This sort of patch merely exchanges one hard-coded color space for another. *A proposed alternative solution:* What about writing code that gets the primaries from the user's chosen RGB working space, and then conveys those primaries to the relevant three functions in libgimpcolor/gimpcolorprofile.c, libgimpcolor/gimprgb.h, and babl/babl-space.c , thereby replacing hard-coded sRGB primaries with "AnyRGB" primaries? "AnyTRC" would need to be considered separately. However, from the point of view of photographic editing, the only really useful TRCs are linear and perceptually uniform. The sRGB TRC is only approximately perceptually uniform. A better hard-coded choice would be the LAB "L" TRC. Though maybe babl already has a way to handle "AnyTRC"? Best, Elle Stone -- https://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
[Gimp-developer] Converting 8-bit integer color palettes to floating point
Hi All, In these two GIMP bug reports: * Support for high bit depth RGB (and LCH?) color palettes for painting https://gitlab.gnome.org/GNOME/gimp/issues/1328 * Add support for Swatchbooker's SBZ colour palette format https://gitlab.gnome.org/GNOME/gimp/issues/2011 are discussions regarding either *converting* GIMP code to use SwatchBooker for high bit depth color palettes, or else *keeping* GIMP GPL palette code (updated to use floating point), and also adding support for importing/exporting SwatchBooker color palettes. Here's the current git repository for SwatchBooker, maintained by Olivier Berten: https://github.com/olivierberten/SwatchBooker Adding support for importing/exporting SwatchBooker color palettes seems like a really good idea for reasons given by "Christoph S" in bug #2011. But converting all GIMP color palette code to use SwatchBooker maybe isn't such a good idea given the reality that maintainers of various free/libre projects do come and go as their lives place various demands on time and energy. Anyway, I did write some barebones working code to convert GIMP color palette code from 8-bit integer to floating point. Details and the patches are in bug #1328. My floating point palette code isn't finished. Well, it's sufficiently finished for my own needs. But I drastically simplified the palette code by removing everything except the core code for opening and saving a palette to/from a GPL file. Otherwise I'd still by trying to figure out which of the many the palette-related files/functions/variables does what. If the GIMP team reaches a consensus to *keep* GIMP's GPL palette code and just update it to be floating point (and of course add support for importing/exporting SwatchBooker assets) - instead of *replacing* GIMP's GPL palette code with SwatchBooker - then I'd go ahead and try to add back into my working patch the various non-core palette functions that I removed to make it easier to figure out the core palette code. Best regards, Elle ___ 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] GIMP-2.99 "No rule to make target 'gimpoperationmaskcomponents.c'"
On 2/17/19 2:46 PM, Ell via gimp-developer-list wrote: On 2/17/19 2:24 PM, Elle Stone wrote: When compiling GIMP-2.99 updated this morning, I got this error: make[4]: *** No rule to make target 'gimpoperationmaskcomponents.c', needed by 'gimpoperationmaskcomponents.o'. Stop. make[4]: *** Waiting for unfinished jobs make[3]: *** [Makefile:984: all-recursive] Error 1 make[2]: *** [Makefile:1266: all-recursive] Error 1 make[1]: *** [Makefile:854: all-recursive] Error 1 make: *** [Makefile:755: all] Error 2 This happens each time we convert a C file to C++. Since both the old .c and new .cc files compile into the same .o file, autofoo is too dumb to smoothly handle that for an existing build. You need to either do fresh build, or, in your build directory, edit app/operations/.deps/gimpoperationmaskcomponents.Po, and change "gimpoperationmaskcomponents.c" to "gimpoperationmaskcomponents.cc", on the first or second line. -- Ell Ell, thanks! compiling from scratch worked. Best, Elle ___ 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] GIMP-2.99 "No rule to make target 'gimpoperationmaskcomponents.c'"
When compiling GIMP-2.99 updated this morning, I got this error: make[4]: *** No rule to make target 'gimpoperationmaskcomponents.c', needed by 'gimpoperationmaskcomponents.o'. Stop. make[4]: *** Waiting for unfinished jobs make[3]: *** [Makefile:984: all-recursive] Error 1 make[2]: *** [Makefile:1266: all-recursive] Error 1 make[1]: *** [Makefile:854: all-recursive] Error 1 make: *** [Makefile:755: all] Error 2 In fact there doesn't seem to be "gimpoperationmaskcomponents.c", though there is "gimpoperationmaskcomponents.cc". Renaming the file and typing "make" to continue compiling results in a bunch of other errors, and "make" doesn't finish. ___ 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] Gtk4
Am Mi., 13. Feb. 2019 um 01:25 Uhr schrieb Massimo Fidanza via gimp-developer-list : Now that Gtk4 is almost done, Gimp 3 will continue target gtk+3 or will switch to Gtk4? If sticking with gtk+3 how difficult will be targeting Gtk4? On 2/13/19 5:32 AM, Tobias Jakobs via gimp-developer-list wrote: from where do you have the information it is almost done? Ff I look into this blog post I don't expect it weeks: https://blog.gtk.org/2019/02/08/report-from-the-gtk-hackfest-in-brussels/ Whether "almost done" means a couple of weeks or a couple of months, I'm guessing GIMP-3.0 won't be released before GTK4.0 is released, yes? So Massimo Fidanza's questions still are interesting questions, that I've also wondered about. I find the release cycle described in these two posts very confusing: https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/ Quoting from the first post, what does this mean? Meanwhile, Gtk 4.0 will not be the final stable API of what we would call “Gtk 4”. Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it. These incompatible minor versions will not be fully parallel installable; they will use the same pkg-config name and the same header file directory. We will, of course, bump the soname with each new incompatible release — you will be able to run Gtk 4.0 apps alongside Gtk 4.2 and 4.4 apps, but you won’t be able to build them on the same system. In particular, what does the part about "you will be able to run GTK4.0 apps alongside Gtk 4.2 and 4.4 apps, but you won't be able to build them on the same system" mean? I recall seeing a similar statement about GTK3, that a software package has to target a specific version of GTK3. So how does the new GTK development cycle actuallly affect GIMP development? I think GIMP-3.0 targets a particular version of GTK3? Will GIMP-4.0 branch be started when GTK-4.6 is released? Will the port from GTK3 to GTK4 be as onerous as the port from GTK2 to GTK3? Best regards, Elle ___ 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] Unable to build GIMP-2.99 on Debian Sid
On 1/29/19 2:00 PM, Elle Stone wrote:
GIMP-2.99 builds just fine on Gentoo. But it won't build on a fresh
install of Debian Sid. It also wouldn't build on Debian testing
The current error in building (having solved several previous "won't
build" errors) seems to be with making the symbolic icons. I don't have
a clue what to do next.
Here's the terminal output:
$ make -j4 > /dev/null
Unescaped left brace in regex is deprecated here (and will be fatal in
Perl 5.32), passed through in regex; marked by <-- HERE in
m/^\s*typedef\s+enum\s*
({ <-- HERE )?\s*
(?:/\*<
(([^*]|\*(?!/))*)
>\s*\*/)?
/ at enumgen.pl line 218.
Name "Gimp::CodeGen::util::FILE_EXT" used only once: possible typo at
enumgen.pl line 34.
Name "Gimp::CodeGen::enums::enums" used only once: possible typo at
enumcode.pl line 30.
Name "Gimp::CodeGen::util::FILE_EXT" used only once: possible typo at
enumcode.pl line 33.
Use of uninitialized value in pattern match (m//) at enumcode.pl line 71.
Can't load file: Unrecognized image file format
Can't load file: Unrecognized image file format
make[3]: *** [Makefile:2363: 64/dialog-question-symbolic.symbolic.png]
Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [Makefile:2363: 64/dialog-warning-symbolic.symbolic.png]
Error 1
Can't load file: Unrecognized image file format
make[3]: *** [Makefile:2363:
64/dialog-information-symbolic.symbolic.png] Error 1
Can't load file: Unrecognized image file format
make[3]: *** [Makefile:2363: 64/dialog-error-symbolic.symbolic.png] Error 1
make[2]: *** [Makefile:719: all-recursive] Error 1
make[1]: *** [Makefile:853: all-recursive] Error 1
make: *** [Makefile:754: all] Error 2
The problem with building on Debian (but not on Gentoo or OpenSUSE)
turned out to be this:
https://www.wiki.gimp.org/wiki/Hacking:Problems_and_solutions#GIMP_build_fails_with_message_.27Couldn.27t_recognize_the_image_file_format_for_file_..2Fcursor-bad.png.27
So it's not a problem with the Symbolic icons, and GIMP did finally
build successfully.
Best,
Elle
--
https://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
[Gimp-developer] Unable to build GIMP-2.99 on Debian Sid
GIMP-2.99 builds just fine on Gentoo. But it won't build on a fresh
install of Debian Sid. It also wouldn't build on Debian testing
The current error in building (having solved several previous "won't
build" errors) seems to be with making the symbolic icons. I don't have
a clue what to do next.
Here's the terminal output:
$ make -j4 > /dev/null
Unescaped left brace in regex is deprecated here (and will be fatal in
Perl 5.32), passed through in regex; marked by <-- HERE in
m/^\s*typedef\s+enum\s*
({ <-- HERE )?\s*
(?:/\*<
(([^*]|\*(?!/))*)
>\s*\*/)?
/ at enumgen.pl line 218.
Name "Gimp::CodeGen::util::FILE_EXT" used only once: possible typo at
enumgen.pl line 34.
Name "Gimp::CodeGen::enums::enums" used only once: possible typo at
enumcode.pl line 30.
Name "Gimp::CodeGen::util::FILE_EXT" used only once: possible typo at
enumcode.pl line 33.
Use of uninitialized value in pattern match (m//) at enumcode.pl line 71.
Can't load file: Unrecognized image file format
Can't load file: Unrecognized image file format
make[3]: *** [Makefile:2363: 64/dialog-question-symbolic.symbolic.png]
Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [Makefile:2363: 64/dialog-warning-symbolic.symbolic.png]
Error 1
Can't load file: Unrecognized image file format
make[3]: *** [Makefile:2363:
64/dialog-information-symbolic.symbolic.png] Error 1
Can't load file: Unrecognized image file format
make[3]: *** [Makefile:2363: 64/dialog-error-symbolic.symbolic.png] Error 1
make[2]: *** [Makefile:719: all-recursive] Error 1
make[1]: *** [Makefile:853: all-recursive] Error 1
make: *** [Makefile:754: all] Error 2
--
https://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] AI algorithms in GIMP
On 1/21/19 10:01 AM, Elle Stone wrote: I don't know if this is the same "super resolution", but FWIW the topic has come up several times on discuss.pixls.us: https://discuss.pixls.us/search?q=%20superresolution My apologies, I wasn't very clear. discuss.pixls.us is a discussion forum for users and developers of free/libre software. Possibly there is already some sort of super-resolution algorithm implementation for one or another free-libre softwares, in which case there is also free/libre code available. But I didn't read any of the links to see what they are actually about. Pat David (the person who runs the forum) might know whether there's any actual implementation with code that might overlap with/be useful for what Maitraya Bhattacharyya is proposing to do. -- https://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] AI algorithms in GIMP
On 1/21/19 8:53 AM, Maitraya Bhattacharyya via gimp-developer-list wrote: super resolution I don't know if this is the same "super resolution", but FWIW the topic has come up several times on discuss.pixls.us: https://discuss.pixls.us/search?q=%20superresolution Best regards, Elle Stone -- https://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] Please Help
On 12/12/2018 04:14 PM, Alexandre Prokoudine via gimp-developer-list wrote: Easter eggs that only show up on April 1 are that bad? Perhaps creepy red flashing eyes (relying on CR's description) isn't the sort of thing that makes people happy, generally speaking? What do you think? ___ 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] Please Help
On 12/12/2018 07:28 AM, C R via gimp-developer-list wrote: Maybe. The eyes flash red under certain circumstances. It's quite creepy... Though this is not a new thing in GIMP.:) If this is an actual fact - that sometimes Wilbur's eyes flash a color - then here is a request that this very odd "feature" be considered a bug and removed. Creepy flashing eye colors randomly appearing under "certain circumstances" is not the sort of behavior that instills confidence in one's editing software. Best regards, Elle ___ 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] Missing include file in current GIMP_2_10 branch
On 11/19/2018 09:33 AM, Ell via gimp-developer-list wrote: Thanks everyone. The file was indeed not being installed. Fixed now, by commit 46d476869985013ea3e620240eaaf445bb3bc5e3. -- Ell Ell - thanks! ___ 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] Missing include file in current GIMP_2_10 branch
On 11/19/2018 06:57 AM, Shlomi Fish wrote: Hi Carmelo, On Mon, 19 Nov 2018 10:46:43 +0100 Carmelo DrRaw via gimp-developer-list wrote: Trying to compile some plug-ins against the current GIMP_2_10 branch, I get errors due to a missing include file: In file included from /usr/local/gimp/include/gimp-2.0/libgimp/gimpui.h:24:0, from print_gimp.h:42, from print-image-gimp.c:27: /usr/local/gimp/include/gimp-2.0/libgimpwidgets/gimpwidgets.h:78:43: fatal error: libgimpwidgets/gimpspinbutton.h: No such file or directory #include compilation terminated. you have a stale installation of the headers under /usr/local. Please remove it. Hmm, I don't install GIMP in /usr/local but rather in a prefix in my home folder. I removed all the files installed by GIMP before updating and doing "git clean -xdf" and recompiling from scratch. Which file/folder in a given install prefix actually contains the "stale installation of the headers"? Looking at the contents of "$PREFIX/include/gimp-2.0/libgimpwidgets/ here are the files - I don't see gimpspinbutton.h: gimp3migration.h gimpbrowser.h gimpbusybox.h gimpbutton.h gimpcairo-utils.h gimpcellrenderercolor.h gimpcellrenderertoggle.h gimpchainbutton.h gimpcolorarea.h gimpcolorbutton.h gimpcolordisplay.h gimpcolordisplaystack.h gimpcolorhexentry.h gimpcolornotebook.h gimpcolorprofilechooserd gimpcolorprofilecombobox gimpcolorprofilestore.h gimpcolorprofileview.h gimpcolorscale.h gimpcolorscales.h gimpcolorselect.h gimpcolorselection.h gimpcolorselector.h gimpcontroller.h gimpdialog.h gimpenumcombobox.h gimpenumlabel.h gimpenumstore.h gimpenumwidgets.h gimpfileentry.h gimpframe.h gimphelpui.h gimphintbox.h gimpicons.h gimpintcombobox.h gimpintstore.h gimpmemsizeentry.h gimpnumberpairentry.h gimpoffsetarea.h gimpoldwidgets.h gimppageselector.h gimppatheditor.h gimppickbutton.h gimppixmap.h gimppreviewarea.h gimppreview.h gimppropwidgets.h gimpquerybox.h gimpruler.h gimpscaleentry.h gimpscrolledpreview.h gimpsizeentry.h gimpstringcombobox.h gimpunitcombobox.h gimpunitmenu.h gimpunitstore.h gimpwidgetsenums.h gimpwidgets-error.h gimpwidgets.h gimpwidgetstypes.h gimpwidgetsutils.h gimpzoommodel.h ___ 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] Four GIMP ICC profile bug reports - the solution is to *embed* GIMP's built-in sRGB profile
1. Add the ability to embed the GIMP built-in sRGB profile upon exporting an image https://gitlab.gnome.org/GNOME/gimp/issues/701 Except for exporting "design" elements for use on a web page, images exported to disk should *always* have an embedded ICC profile. The only reason GIMP is in this mess today is because web designers complained more loudly than photographers, way back when. 2. Original ICC profile sometimes embedded in exported file even after converting to built-in sRGB https://gitlab.gnome.org/GNOME/gimp/issues/1645 The solution to this problem is to always *embed* GIMP's built-in sRGB profile in place of the originally embedded ICC profile, OR at the user's option and specifically for web designers, strip away the originally embedded ICC profile before exporting the file as an sRGB image. 3. exif tags and embedded color space profile not synchronized https://gitlab.gnome.org/GNOME/gimp/issues/301 The solution to this problem is to *embed* an ICC profile, including GIMP's built-in sRGB profile. Don't automatically alter or delete the original camera-generated exif tags - altering or deleting such data is something that should be left up to user initiative. 4. exporting to jpeg from 32-bit float linear image produces jpeg in linear color space https://gitlab.gnome.org/GNOME/gimp/issues/1070 The solution to this problem is to *always* convert the image to 32-bit "gamma" precision before exporting an image as an 8-bit jpeg, and then *embed* the built-in sRGB profile, assuming of course the image in fact is in one of GIMP's built-in sRGB color spaces. The user shouldn't have to take extra steps to make this happen. Jpeg compression is designed to work with perceptually uniform RGB. It might be nice to add a user option to override the automatic conversion to perceptually uniform RGB before exporting an image. But the only reason I can think of to export a linear gamma sRGB image to disk is to show that it's really not a good idea because of resulting compression artifacts. In any event, all such exported sRGB images should have an embedded sRGB ICC profile, except for the pathological case (web browsers being pathological in their variously incorrect ways of doing color management) of exporting an image to disk for use as a web design element, in which case the image absolutely must be converted to perceptually uniform sRGB before being exported without an embedded ICC profile. ___ 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] how to build json-glib in a prefix when building gimp from git in a prefix?
Many thanks to everyone who helped sort out how to build json-glib. I did finally manage to build json-glib in a prefix on Gentoo, using these commands: $PREFIX=PREFIX=$HOME/code-install/gimp299/install cd json-glib mkdir build cd build meson --prefix=$PREFIX .. ninja install Best, Elle On 09/30/2018 06:36 AM, Ken Moffat via gimp-developer-list wrote: On Sun, Sep 30, 2018 at 10:44:38AM +0200, wwp wrote: Hello Ken, Hi wwp, On Sun, 30 Sep 2018 02:33:34 +0100 Ken Moffat via gimp-developer-list wrote: On Sun, Sep 30, 2018 at 12:00:40AM +0100, Ken Moffat via gimp-developer-list wrote: On Sat, Sep 29, 2018 at 06:21:36PM -0400, Elle Stone wrote: I don't know what version json-glib from git is on. I cloned it as follows: git clone https://gitlab.gnome.org/GNOME/json-glib But I'd be happy to download a specific tarball, if anyone knows what version of json-glib is currently required by GIMP. Are you sure you need json-glib ? Json-glib *is* needed to build gimp 2.10. I build gimp 2.8/2.10 on CentOS 6 and 7 boxes, where no package is available (for the latest 2.8 and 2.10 at all), and I build quite all the necessary deps (it's a lot and the cross-deps are a nightmare), json-glib is required at some step. From what I see in my build script, gegl 0.3/0.4 need it. Yeah, you are right. I thought it must be a new dep for gimp itself. And I didn't remember using it. But now that I look at my scripts I can see that it is GEGL which needs it. So for Elle, the version is whatever your GEGL needs. A quick look at https://gitlab.gnome.org/GNOME/gegl/blob/master/configure.ac suggests json-glib-1.0 which both json-glib-1.2 and -1.4 (and probably even -1.0) provided. ĸen -- https://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] how to build json-glib in a prefix when building gimp from git in a prefix?
On 09/29/2018 05:18 PM, Ken Moffat via gimp-developer-list wrote: On Sat, Sep 29, 2018 at 03:23:24PM -0400, Elle Stone wrote: Anyone know the precise terminal commands for building json-glib in a prefix using meson? I'm trying to update this article: https://ninedegreesbelow.com/photography/build-gimp-in-prefix-for-artists.html I already established the prefix using these commands: PREFIX=$HOME/code/gimpdefault/install export PATH=$PREFIX/bin:$PATH export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/share/pkgconfig:$PKG_CONFIG_PATH export GIO_EXTRA_MODULES=/usr/lib64/gio/modules export SRC_DIR=$HOME/code/gimpdefault/build I'm building on OpenSUSE Tumbleweed. Probably I need to install meson something or other, so does anyone know what package(s) to install? And then of course what commands to type. Best, and thanks in advance for any help! Elle Hi Elle, I don't know how OpenSUSE splits packages into sub-packages (-dev or something for headers), but the upstream packages you will need are meson, ninja, and python3. Well, on my main computer I run Gentoo. Failing to build json-glib on the upstairs computer (which runs OpenSUSE), I thought I'd try on my main computer, but I'm having the same problems. For building meson in /usr, see http://www.linuxfromscratch.org/blfs/view/svn/general/json-glib.html Note that is still on 1.4.2 which is probably older than what you are going to build. I don't know what version json-glib from git is on. I cloned it as follows: git clone https://gitlab.gnome.org/GNOME/json-glib But I'd be happy to download a specific tarball, if anyone knows what version of json-glib is currently required by GIMP. I don't think the _process_ of using meson has changed recently: create a build directory, change to it, invoke meson with whatever switches you need (a minimum of --prefix=) followed by .. to point to where the meson files are. I've never built anything using meson before. So I don't know how it was done before or how it should be done now. I made a directory called "build" within the clonse json-glib folder and cd'ed to is, and then used this command to set the prefix: meson configure --prefix=$PREFIX Which resulted in this error: Meson configurator encountered an error: ERROR: Directory /hdd/data1/code-build/gimp299/build/json-glib/build does not seem to be a Meson build directory. For some options you may need cmake-style -Dfoo=bar. I have found it necessary to export LC_ALL with a UTF-8 value, e.g. en_GB.UTF-8, if invoking meson from a script running under the C or POSIX locales. I don't know what you are talking about. I have my locale information set to UTF-8. I don't know what "script running under the C or POSIX locales" actually means - can you explain? And ninja will use all your cores, although for json-glib that is probably immaterial. So, use meson to create the Makefile(s), ninja to build, ninja install. For a DESTDIR-style install to check what is going to be installed: DESTDIR=/tmp/JG ninja install (i.e. put the DESTDIR first) Please, having cd'ed to the "build" folder inside the json-glib folder, what's the next thing to type? Personally I don't care if I never build json-glib from source as the Gentoo version is plenty recent enough for building GIMP from git. But I'm trying to update my website article for people who *do* need to build json-glib from source. In BLFS we target linuxfromscratch which includes meson and ninja, so those are not listed as dependencies, and the build time uses LFS's "standard build units" (SBU) - for json-glib the time should only be a few seconds on any modern machine. Other deps are whatever any 'Required' or 'Recommended' packages specify - but since you probably already have glib and gobject-introspection I guess you have everything necessary. Also, in BLFS we only use lib, not lib64, I'm not sure if that will affect meson. Old docs from fedora suggest --libdir, but I don't Gentoo uses "lib". OpenSUSE uses "lib64" or at least used to. Probably I should check to see what's currently being used on OpenSUSE. But right now I'm sitting at my Gentoo machine trying to do a test install of json-glib. immediately see that in their latest build, so I suggest you try without, and if it builds do a DESTDIR install to see if the files are where you expect them to be. For building with meson the important files are meson.build and meson_options.txt. From the first, for json-glib-1.4.2 meson needs to be >= 0.40.1, glib >= 2.44.0, and from the second, introspection defaults to true but can be set to false if you don't have gobject-introspection, and On Gentoo I have dev-util/meson-0.46.1 and dev-util/ni
[Gimp-developer] how to build json-glib in a prefix when building gimp from git in a prefix?
Anyone know the precise terminal commands for building json-glib in a prefix using meson? I'm trying to update this article: https://ninedegreesbelow.com/photography/build-gimp-in-prefix-for-artists.html I already established the prefix using these commands: PREFIX=$HOME/code/gimpdefault/install export PATH=$PREFIX/bin:$PATH export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export PKG_CONFIG_PATH=$PREFIX/share/pkgconfig:$PKG_CONFIG_PATH export GIO_EXTRA_MODULES=/usr/lib64/gio/modules export SRC_DIR=$HOME/code/gimpdefault/build I'm building on OpenSUSE Tumbleweed. Probably I need to install meson something or other, so does anyone know what package(s) to install? And then of course what commands to type. Best, and thanks in advance for any help! Elle ___ 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] usability: 72 year old has trouble with dark padding
On 08/28/2018 05:09 AM, Laxminarayan Kamath via gimp-developer-list wrote: Hi, To those studying/working on the usability aspect of GIMP, here is an interesting case: https://m.facebook.com/groups/1921288214858432?view=permalink=2119666095020642 Not everyone is a member of facebook. Could you summarize the problem the person is having with the dark padding? I'm guessing that "dark padding" refers to the dark theme. There is also a middle gray and a light theme, in addition to the dark theme. When the themes were being developed, there was input from various people with various issues with themes that were "too bright" and also with themes that were "too dark", hence the three choices. Best, Elle ___ 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] Terminal warnings when starting GIMP-2.10/2.99 - mypaint-related?
On 08/25/2018 08:53 AM, Elle Stone wrote:
Recently when I start GIMP compiled from git, I get a whole bunch of
terminal warnings that look to be mypaint-related.
Is anyone else seeing these? Is there something I should update/change/etc?
OK, I just got a private email suggesting that GIMP was looking for
mypaint brushes in $HOME/.mypaint and that perhaps I had a modified set
of mypaint brushes from a "not default" installation of mypaint. Which
was exactly the case.
So I removed $HOME/.mypaint from the list of folders GIMP could look in
for mypaint brushes, and that got rid of the terminal warnings.
I don't know if the person who sent the private email really did mean
only to respond to me. But in any case thanks! that solved the problem.
Best,
Elle
Here's the code I use to compile libmypaint and the brushes:
cd $SRC_DIR/libmypaint
make uninstall & make clean
git clean -xdf
git pull
git checkout v1.3.0
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" ./autogen.sh --prefix=$PREFIX
./configure --prefix=$PREFIX
# Unless something has changed recently,
# for libmypaint you do need to run ./autogen.sh and then ./configure
make -j4 && make -j4 install
cd $SRC_DIR/mypaint-brushes
make uninstall && make clean
git clean -xdf
git pull
git checkout v1.3.0
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" ./autogen.sh --prefix=$PREFIX
./configure --prefix=$PREFIX
# You do need to run ./autogen.sh and then ./configure
make -j4 && make -j4 install
Here's the terminal warnings when I run GIMP:
Warning: Unknown setting_id: -1 for setting: gridmap_scale
Warning: Unknown setting_id: -1 for setting: gridmap_scale_x
Warning: Unknown setting_id: -1 for setting: gridmap_scale_y
Warning: Unknown setting_id: -1 for setting: offset_angle
Warning: Unknown setting_id: -1 for setting: offset_angle_2
Warning: Unknown setting_id: -1 for setting: offset_angle_2_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_2_view
Warning: Unknown setting_id: -1 for setting: offset_angle_adj
Warning: Unknown setting_id: -1 for setting: offset_angle_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_view
Warning: Unknown setting_id: -1 for setting: offset_multiplier
Warning: Unknown setting_id: -1 for setting: offset_x
Warning: Unknown setting_id: -1 for setting: offset_y
Warning: Unknown setting_id: -1 for setting: posterize
Warning: Unknown setting_id: -1 for setting: posterize_num
Warning: Unknown setting_id: -1 for setting: smudge_bucket
Warning: Unknown setting_id: -1 for setting: smudge_darken
Warning: Unknown setting_id: -1 for setting: smudge_desaturation
Warning: Unknown setting_id: -1 for setting: smudge_gamma
Warning: Unknown setting_id: -1 for setting: smudge_length_log
Warning: Unknown setting_id: -1 for setting: smudge_normal_sub
Warning: Unknown setting_id: -1 for setting: smudge_spectral
Warning: Unknown setting_id: -1 for setting: smudge_transparency
Warning: Unknown setting_id: -1 for setting: gridmap_scale
Warning: Unknown setting_id: -1 for setting: gridmap_scale_x
Warning: Unknown setting_id: -1 for setting: gridmap_scale_y
Warning: Unknown setting_id: -1 for setting: offset_angle
Warning: Unknown setting_id: -1 for setting: offset_angle_2
Warning: Unknown setting_id: -1 for setting: offset_angle_2_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_2_view
Warning: Unknown setting_id: -1 for setting: offset_angle_adj
Warning: Unknown setting_id: -1 for setting: offset_angle_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_view
Warning: Unknown setting_id: -1 for setting: offset_multiplier
Warning: Unknown setting_id: -1 for setting: offset_x
Warning: Unknown setting_id: -1 for setting: offset_y
Warning: Unknown setting_id: -1 for setting: posterize
Warning: Unknown setting_id: -1 for setting: posterize_num
Warning: Unknown setting_id: -1 for setting: smudge_bucket
Warning: Unknown setting_id: -1 for setting: smudge_darken
Warning: Unknown setting_id: -1 for setting: smudge_desaturation
Warning: Unknown setting_id: -1 for setting: smudge_gamma
Warning: Unknown setting_id: -1 for setting: smudge_length_log
Warning: Unknown setting_id: -1 for setting: smudge_normal_sub
Warning: Unknown setting_id: -1 for setting: smudge_spectral
Warning: Unknown setting_id: -1 for setting: smudge_transparency
Warning: Unknown setting_id: -1 for setting: gridmap_scale
Warning: Unknown setting_id: -1 for setting: gridmap_scale_x
Warning: Unknown setting_id: -1 for setting: gridmap_scale_y
Warning: Unknown setting_id: -1 for setting: offset_angle
Warning: Unknown setting_id: -1 for setting: offset_angle_2
Warning: Unknown setting_id: -1 for setting: offset_angle_2_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_2_view
Warning: Unknown setting_id: -1 for setting: offset_angle_adj
Warning: Unknown setting_id
[Gimp-developer] Terminal warnings when starting GIMP-2.10/2.99 - mypaint-related?
Recently when I start GIMP compiled from git, I get a whole bunch of
terminal warnings that look to be mypaint-related.
Is anyone else seeing these? Is there something I should update/change/etc?
Here's the code I use to compile libmypaint and the brushes:
cd $SRC_DIR/libmypaint
make uninstall & make clean
git clean -xdf
git pull
git checkout v1.3.0
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" ./autogen.sh --prefix=$PREFIX
./configure --prefix=$PREFIX
# Unless something has changed recently,
# for libmypaint you do need to run ./autogen.sh and then ./configure
make -j4 && make -j4 install
cd $SRC_DIR/mypaint-brushes
make uninstall && make clean
git clean -xdf
git pull
git checkout v1.3.0
CFLAGS="-march=native -O3 -ffast-math -ftree-vectorize -pipe"
CXXFLAGS="${CFLAGS}" ./autogen.sh --prefix=$PREFIX
./configure --prefix=$PREFIX
# You do need to run ./autogen.sh and then ./configure
make -j4 && make -j4 install
Here's the terminal warnings when I run GIMP:
Warning: Unknown setting_id: -1 for setting: gridmap_scale
Warning: Unknown setting_id: -1 for setting: gridmap_scale_x
Warning: Unknown setting_id: -1 for setting: gridmap_scale_y
Warning: Unknown setting_id: -1 for setting: offset_angle
Warning: Unknown setting_id: -1 for setting: offset_angle_2
Warning: Unknown setting_id: -1 for setting: offset_angle_2_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_2_view
Warning: Unknown setting_id: -1 for setting: offset_angle_adj
Warning: Unknown setting_id: -1 for setting: offset_angle_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_view
Warning: Unknown setting_id: -1 for setting: offset_multiplier
Warning: Unknown setting_id: -1 for setting: offset_x
Warning: Unknown setting_id: -1 for setting: offset_y
Warning: Unknown setting_id: -1 for setting: posterize
Warning: Unknown setting_id: -1 for setting: posterize_num
Warning: Unknown setting_id: -1 for setting: smudge_bucket
Warning: Unknown setting_id: -1 for setting: smudge_darken
Warning: Unknown setting_id: -1 for setting: smudge_desaturation
Warning: Unknown setting_id: -1 for setting: smudge_gamma
Warning: Unknown setting_id: -1 for setting: smudge_length_log
Warning: Unknown setting_id: -1 for setting: smudge_normal_sub
Warning: Unknown setting_id: -1 for setting: smudge_spectral
Warning: Unknown setting_id: -1 for setting: smudge_transparency
Warning: Unknown setting_id: -1 for setting: gridmap_scale
Warning: Unknown setting_id: -1 for setting: gridmap_scale_x
Warning: Unknown setting_id: -1 for setting: gridmap_scale_y
Warning: Unknown setting_id: -1 for setting: offset_angle
Warning: Unknown setting_id: -1 for setting: offset_angle_2
Warning: Unknown setting_id: -1 for setting: offset_angle_2_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_2_view
Warning: Unknown setting_id: -1 for setting: offset_angle_adj
Warning: Unknown setting_id: -1 for setting: offset_angle_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_view
Warning: Unknown setting_id: -1 for setting: offset_multiplier
Warning: Unknown setting_id: -1 for setting: offset_x
Warning: Unknown setting_id: -1 for setting: offset_y
Warning: Unknown setting_id: -1 for setting: posterize
Warning: Unknown setting_id: -1 for setting: posterize_num
Warning: Unknown setting_id: -1 for setting: smudge_bucket
Warning: Unknown setting_id: -1 for setting: smudge_darken
Warning: Unknown setting_id: -1 for setting: smudge_desaturation
Warning: Unknown setting_id: -1 for setting: smudge_gamma
Warning: Unknown setting_id: -1 for setting: smudge_length_log
Warning: Unknown setting_id: -1 for setting: smudge_normal_sub
Warning: Unknown setting_id: -1 for setting: smudge_spectral
Warning: Unknown setting_id: -1 for setting: smudge_transparency
Warning: Unknown setting_id: -1 for setting: gridmap_scale
Warning: Unknown setting_id: -1 for setting: gridmap_scale_x
Warning: Unknown setting_id: -1 for setting: gridmap_scale_y
Warning: Unknown setting_id: -1 for setting: offset_angle
Warning: Unknown setting_id: -1 for setting: offset_angle_2
Warning: Unknown setting_id: -1 for setting: offset_angle_2_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_2_view
Warning: Unknown setting_id: -1 for setting: offset_angle_adj
Warning: Unknown setting_id: -1 for setting: offset_angle_asc
Warning: Unknown setting_id: -1 for setting: offset_angle_view
Warning: Unknown setting_id: -1 for setting: offset_multiplier
Warning: Unknown setting_id: -1 for setting: offset_x
Warning: Unknown setting_id: -1 for setting: offset_y
Warning: Unknown setting_id: -1 for setting: posterize
Warning: Unknown setting_id: -1 for setting: posterize_num
Warning: Unknown setting_id: -1 for setting: smudge_bucket
Warning: Unknown setting_id: -1 for setting: smudge_darken
Warning: Unknown setting_id: -1 for setting: smudge_desaturation
Warning: Unknown setting_id: -1 for setting: smudge_gamma
Warning: Unknown setting_id: -1 for setting:
Re: [Gimp-developer] #gimp irc invitation only?
Hi All, For two days now I've wanted to log into #gimp IRC and ask a question. I think right now I can now log in the way I always have, without identifying myself as really me, belonging to my registered nickname. But what I really want to know is how to actually join a channel and at the same time identify myself. I have a generic chatzilla window open. What, exactly, do I type to join #gimp and at the same time identify myself? I've perused the internet several times over the last two days and come up with a whole lot of stuff, none of which actually lists the actual specific commands to type. Best, Elle ___ 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] #gimp irc invitation only?
On 08/23/2018 12:33 PM, Akkana Peck wrote: Elle Stone writes: It does seem that irc.gimp.org and freenode.org require separate registration. Or else there is some sort of time lag wrt something done with freenode reaching irc.gimp.org. In any event, now I'm registered and identified. But there is still a message about "invite-only". For what it's worth, I'm getting the same "invite-only" message Elle is. If I /msg nickserv status from #gimp-users (which doesn't seem to have the same restriction), it says I'm status 3, which supposedly means I'm logged in. ...Akkana Akkana, thanks! for letting me know I'm not the only person seeing the "invite-only" message. Best, Elle ___ 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] #gimp irc invitation only?
On 08/23/2018 11:47 AM, Paka wrote: * Elle Stone [08-23-18 11:42]: On 08/23/2018 11:25 AM, Paka wrote: This channel is invite-only. You must have an invite from an existing member of the channel to join. Use "/knock #gimp" to ask the channel operators to invite you in. it was instituted freenode wide to accept *only* registered users due to spamming. it requires you "log" in using a password to your *registered* id. go to #freenode make sure your nick is correctly set /msg nickserv identify Hi Paka, I just did register with #freenode. But I still get the same "invite-only" message when trying to join #gimp. Is freenode even related to irc.gimp.org? no, not "related". freenode provides irc service connections and I can access #gimp from there. paka (~paka@opensuse/member/Paka) has joined #gimp Does freenode handle all nick registrations? as far as I know Does irc.gimp.org require separate registraton? "registering" alone is not enough, did you do "/msg nickserv identify " Hi Paka, It does seem that irc.gimp.org and freenode.org require separate registration. Or else there is some sort of time lag wrt something done with freenode reaching irc.gimp.org. In any event, now I'm registered and identified. But there is still a message about "invite-only". Best, Elle ___ 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] #gimp irc invitation only?
On 08/23/2018 11:25 AM, Paka wrote: * Elle Stone [08-23-18 11:18]: On 01/15/2018 03:32 PM, Michael Schumacher wrote: On 01/15/2018 09:17 PM, Elle Stone wrote: [INFO] This channel is invite-only. You must have an invite from an existing member of the channel to join. Use "/knock #gimp" to ask the channel operators to invite you in. [Knock] Any ideas what's going on? There was a netsplit, and when reconnecting, one of the servers set the channel mode to +i(nvite only) There is no obvious reason why it should be set this way, so I changed it back. Hmm, the same thing just happened again: This channel is invite-only. You must have an invite from an existing member of the channel to join. Use "/knock #gimp" to ask the channel operators to invite you in. it was instituted freenode wide to accept *only* registered users due to spamming. it requires you "log" in using a password to your *registered* id. go to #freenode make sure your nick is correctly set /msg nickserv identify Hi Paka, I just did register with #freenode. But I still get the same "invite-only" message when trying to join #gimp. Is freenode even related to irc.gimp.org? Does freenode handle all nick registrations? Does irc.gimp.org require separate registraton? Best, Elle ___ 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] #gimp irc invitation only?
On 01/15/2018 03:32 PM, Michael Schumacher wrote: On 01/15/2018 09:17 PM, Elle Stone wrote: [INFO] This channel is invite-only. You must have an invite from an existing member of the channel to join. Use "/knock #gimp" to ask the channel operators to invite you in. [Knock] Any ideas what's going on? There was a netsplit, and when reconnecting, one of the servers set the channel mode to +i(nvite only) There is no obvious reason why it should be set this way, so I changed it back. Hmm, the same thing just happened again: This channel is invite-only. You must have an invite from an existing member of the channel to join. Use "/knock #gimp" to ask the channel operators to invite you in. Best, Elle ___ 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] [Gimp-gui] GTK3 "empty black window"/"black flash" bug that affects GIMP-2.99
On 08/05/2018 07:30 AM, Jehan wrote: Yeah well, I saw a lot of similar drag'n drop issues on the master branch. But that is another problem: the master branch is not for production and has a lot lot of bugs, until we fix them. It's just a fact and that's why we don't advise anyone to use GIMP master for actual work. Well, this particular "can't grab the place to move the divider line" issue seems directly linked to using/not using the version of GTK-3.22.30 that I downloaded and patched, vs the unpatched version from Gentoo portage. The reason I'm using GIMP git master is to help test some ongoing changes in the code that affects color management. I wouldn't advise anyone to stop using 2.10 and switch to 2.99 unless they are likewise planning to help test the code - 2.99 does crash quite a lot even on Linux. Though the crash recovery code - that I think Jehan had a large part in writing, yes? - does work really well :) . Best, Elle ___ 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] [Gimp-gui] GTK3 "empty black window"/"black flash" bug that affects GIMP-2.99
On 08/05/2018 05:22 AM, Jehan wrote: Checking the latest 3.30 tarball from http://ftp.gnome.org/pub/gnome/sources/gtk+/3.22/, it appears the fix hasn't been incorporated into any actual GTK3 releases. I was wondering what you meant by 3.30. You meant 3.22.30, last release of 3.22. Oh, drat, of course it should be 3.22.30 - the download folder link I gave is correct, but I accidentally left the ".22" out when referring to the actual version of GTK3 that I downloaded and patched - sorry! Also I just checked, your commit is available in a release: 3.23.0 which is an unstable release. We are actually waiting a bit to bump the dependency of GTK+ a bit, but we are planning to. I also wait for a fix I made (also available in 3.23.0) and Mitch told me he also has a commit there. So this bump will happen sooner rather than later, no problem. :-) Yeah! So I downloaded the latest GTK3 tarball, applied the fix (involves adding a couple of extra lines of code to gdk/x11/gdkwindow-x11.c), and compiled/installed it in my GIMP-2.99 prefix. This fix does indeed get rid of the "black flash" problem. My patched version of 3.22.30 did get rid of the "black window" problem, but also seems to have introduced an issue where it was no longer possible to grab the center left-right panel dividing line when using a toolbox in multi-window mode. Leastways going back to the Gentoo-installed 3.22.30 did get rid of the problem of not being able to grab and move the center dividing line. Bleh. You may also use the unstable tarballs from 3.23 so that you don't have to patch yourself. :-) https://download.gnome.org/sources/gtk+/3.23/ I'll give that a try -thanks! for the link. Best, Elle Thanks anyway for this informative email! Jehan ___ 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] GTK3 "empty black window"/"black flash" bug that affects GIMP-2.99
Hi All, This is just an FYI for anyone who encounters the issue and doesn't already know about this bug. There is a long-standing GTK3 bug - that's recently been fixed in GTK git master - that does affect GIMP-2.99. I noticed it yesterday when I tried for the first time to use GIMP-2.99 for actual editing. This bug causes an empty black window to briefly appear when opening editing dialog windows such as "Filters/Blur/Gaussian Blur". FWIW, this GTK3 bug was reported back in 2015 for GTK3 version 3.22.x, and there is a trail of bug reports on various OS's running various desktops, including: Black background appears briefly before window gets drawn: https://bugzilla.gnome.org/show_bug.cgi?id=748498 https://gitlab.gnome.org/GNOME/gtk/issues/550 GTK3 windows appear with a black flash: https://bugzilla.gnome.org/show_bug.cgi?id=771708 https://bugzilla.redhat.com/show_bug.cgi?id=1370791 Black background appears briefly before window gets drawn: https://gitlab.gnome.org/GNOME/gtk/issues/550 The fix was committed here, three months ago: x11: Set a transparent background on windows by default "This avoids black flicker on compositing WMs when a window is first shown." https://gitlab.gnome.org/GNOME/gtk/commit/2ce63a86ba689aa41eb47409c889c469497478b0 I noticed the "empty black window" bug when opening GIMP-2.99 editing dialogs such as "Curves" and "Gaussian Blur", on both Gentoo (updated a couple of week ago) and OpenSUSE Tumbleweed (updated today). Both of these OS's use GTK3 version 3.30. Checking the latest 3.30 tarball from http://ftp.gnome.org/pub/gnome/sources/gtk+/3.22/, it appears the fix hasn't been incorporated into any actual GTK3 releases. So I downloaded the latest GTK3 tarball, applied the fix (involves adding a couple of extra lines of code to gdk/x11/gdkwindow-x11.c), and compiled/installed it in my GIMP-2.99 prefix. This fix does indeed get rid of the "black flash" problem. Best, Elle -- https://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
[Gimp-developer] Error when trying to connect to IRC: All connections in use
Recently, when I try to connect to #GIMP IRC, somtimes there is an error message: [INFO] Connecting to irc://irc.gimp.org/ (irc://irc.gimp.org/)… [Cancel] [ERROR] All connections in use [ERROR] Connection to irc://irc.gimp.org/ (irc://irc.gimp.org/) closed. [Help] Reconnecting in 15 seconds. [Cancel] Is #GIMP IRC suddenly a lot more popular than it used to be? Or is there some other problem? Best, Elle ___ 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] Image Colour Analysis
On 06/25/2018 05:41 AM, GiuseppeD. via gimp-developer-list wrote: Dears, I would do a colour analysis on my picture. I already took picture with a colour palette for calibration. What do I do now for calibrate with my colour reference? How can I have RGB data after the calibration? Thanks Hi, What is this "picture with a colour palette for calibration" used for? Can you provide a link to the actual image? Is the picture for setting white point, black point, and color balance when the picture is included in the camera shot, as per this bug report? https://gitlab.gnome.org/GNOME/gimp/issues/624 Best regards, Elle -- https://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] Git and Bugzilla migration to gitlab.gnome.org - action items and important hints
On 06/03/2018 10:25 AM, Kevin Cozens wrote: On 2018-06-03 09:04 AM, Elle Stone wrote: I see "Global" in the drop-down list. But where are the Global settings? After you log in click the circle in the top right corner and select Settings. On the page that pops up click the Notfications link that is half-way down the left-hand side set of choices. Your description of where to click is very clear, even to someone like myself who'd never ever think to click on some unlabelled and uninformative icon - thanks! There is also "Watch" - is this the equivalent of getting all GIMP bug reports in the way that such was done for Bugzilla? There is also "On mention" and "Participate". Does "On mention" include "Participate"? Can both be checked? The "Custom" option under the Global notifications offers more control. Has anyone else managed to set up getting emails in a way that's equivalent to emails sent out by Bugzilla? AFAICT, we don't have the same level of controls over notifications as we had with Bugzilla. The use of Custom notification settings, either at the project level or at the Global level, is as close as we can get. Hmm, that Notifications page is not exactly clear. Apparently I'm a member of the Group GNOME and the Project GIMP. So I did the following: * Set Global notifications to "On mention" and checked the box to "Receive notifications about your own activity", so hopefully this will apply to all GNOME Projects other than GIMP, and will only result in emails if I actually ever file a bug report with a GNOME Project other than GIMP. * Set the GIMP "Project" notifications to "Watch", in the hopes that this is equivalent to the settings I had on Bugzilla, where I got copies of all GIMP bug report comments, closings, etc. Hopefully the above settings won't result in a total flood of unwanted emails! Regarding Custom notification settings, the descriptions of the various options are as clear as mud. Is there a link to actually understandable explanations of the available custom options? Or a list of recommended options to check? Best, Elle ___ 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] Git and Bugzilla migration to gitlab.gnome.org - action items and important hints
On 06/02/2018 06:11 PM, Michael Schumacher wrote: Maybe there is a link to a page with the requested information, that someone would be willing to share? Notification settings can be changed per project on the project pages - e.g. onhttps://gitlab.gnome.org/GNOME/gimp The default is to use Global default settings, but this can be changed to receive everything about a project, or just explicitly watched issues, mentions of Hi Michael, Thanks! for the link. I see "Global" in the drop-down list. But where are the Global settings? Or are these not user-settable? This page makes it sound like somewhere there are Global settings that are user-controllable, but what's the link to the page for making changes to global settings, assuming this is possible? https://gitlab.gnome.org/help/workflow/notifications There is also "Watch" - is this the equivalent of getting all GIMP bug reports in the way that such was done for Bugzilla? There is also "On mention" and "Participate". Does "On mention" include "Participate"? Can both be checked? Has anyone else managed to set up getting emails in a way that's equivalent to emails sent out by Bugzilla? If so, what settings did you use, by accessing which pages on gitlab? Best, Elle ___ 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] Git and Bugzilla migration to gitlab.gnome.org - action items and important hints
On 05/31/2018 12:01 PM, Elle Stone wrote: On 05/22/2018 05:46 PM, Michael Schumacher wrote: Everyone who is receiving Bugzilla mails for comments and status changes of GIMP bugs will receive about 1400 mails. If you do not want this, disable mail on your Bugzilla preferences or unwatch theb...@gimp.org user there temporarily: https://bugzilla.gnome.org/userprefs.cgi?tab=email Bugzilla will stay around for bug research, but no bug tracking will happen there for migrated projects anymore. Hi Michael and All, How/where does one sign up to receive gitlab mails for comments and status changes of GIMP bugs? I'm guessing that re-enabling Bugzilla preferences won't do the trick. Maybe there is a link to a page with the requested information, that someone would be willing to share? Best, Elle ___ 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] Git and Bugzilla migration to gitlab.gnome.org - action items and important hints
On 05/22/2018 05:46 PM, Michael Schumacher wrote: Everyone who is receiving Bugzilla mails for comments and status changes of GIMP bugs will receive about 1400 mails. If you do not want this, disable mail on your Bugzilla preferences or unwatch theb...@gimp.org user there temporarily: https://bugzilla.gnome.org/userprefs.cgi?tab=email Bugzilla will stay around for bug research, but no bug tracking will happen there for migrated projects anymore. Hi Michael and All, How/where does one sign up to receive gitlab mails for comments and status changes of GIMP bugs? I'm guessing that re-enabling Bugzilla preferences won't do the trick. GitLab uses the term "Issues" instead of "Bugs". Once we're migrated we'll start fine-tuning the project settings and provide an update mail about any important changes. Are the gitlab project settings already fine-tuned enough to allow receiving gitlab mails for GIMP bugs? Is there a way in gitlab to add oneself to receive comments on a given bug, without actually making a comment to the specific bug? Maybe there's a totally obvious way to do this, but if so I didn't see it. Best, Elle ___ 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] GIMP branched: new stable branch gimp-2-10
On 05/22/2018 11:09 AM, Jehan Pagès wrote: Gtk4 doesn't have a Mac backend AFAIK and I'm not sure it's widely tested on Windows Hmm, this page seems to indicate GTK+4 does/will have support for MacOs: https://www.phoronix.com/scan.php?page=news_item=GTK-3.91-Released quoting: "GTK+ 3.91 brings initial Meson build system support, GTK4 native support for macOS, and nearly two dozen bug fixes." Best, Elle ___ 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] GIMP branched: new stable branch gimp-2-10
On 05/21/2018 11:13 AM, Jehan Pagès wrote: Just to be clear, the toolkit update here is not*just* a necessary evil. It will also be totally awesome, even feature-wise! Simply to get there, we have to pass through an "unstable" phase, that's all there is to it. Hi All, Apparently GTK+3.22 is considered "long term stable" (that is, supported for three years? starting from when?) and is the last minor release in the GTK+3 series: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ Will the port to GTK+3 be finished before the apparently planned initial release of GTK+4 later this year (https://blogs.gnome.org/mclasen/2018/02/03/gtk-hackfests-day-2/)? Will the port from GTK+3 to GTK+4 be as difficult as the port from GTK+2 to GTK+3? Looking at various NEWS postings in the 3.93/.92/etc releases leading up to GTK+4 (http://ftp.acc.umu.se/pub/gnome/sources/gtk+/), it looks like a fair amount of stuff will change. Best, Elle ___ 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] GIMP branched: new stable branch gimp-2-10
Hi All, On 05/20/2018 05:23 PM, Elle Stone wrote: On 05/20/2018 04:31 PM, Michael Natterer wrote: On Sun, 2018-05-20 at 21:27 +0200, Carmelo DrRaw wrote: What is the recommended branch for nightly development snapshots? Should one provide snapshots for both master and gimp-2-10? That depends on what you want or what these snapshots are for: gimp-2-10 is where 2.10.x releases are made from. master is bleeding edge. Is current git master more or less stable for actual use? For context, I started using GIMP-2.9 back in 2013 and from my point of view it was already sufficiently stable. I don't mind the occasional crash (well, assuming the crash doesn't destroy XCF files that aren't actually open for editing). Regarding which branch to use for editing (as opposed to which branch(es) to provide for users to choose from), over on the gimp-gui mailing list Jehan had this to say about the new gimp git master branch, post-merging with the gtk+3 branch: A note: are you actually planning on working with master? Even though for the last few years, master was absolutely production-usable, this is not the case with new master with GTK+3. A lot of stuff is broken on the GTK+3 port. As I write this, I am working on the icon themes for instance which are completely broken. This is not production-ready. If you want a moving target while still stay usable, build "gimp-2-10" branch (which is old master). I predict it will still stay quite active, much more than what the "gimp-2-8" branch used to be since we will continue to backport features when possible/not too hard. I had asked on the gimp-gui mailing list about some issues with the GTK+3/"new git" branch GTK+3 user interface. Even apart from other stuff that might be broken, the current git GIMP master GTK+3 interface is not very nice to use, at least not as it appears on my computer. The thread is here, if anyone is interested: https://mail.gnome.org/archives/gimp-gui-list/2018-May/thread.html and click on the thread "gimp git master branch user interface". Personally I've decided to hold off switching to the "new git/GTK+3" branch and stick with the 2.10 branch, at least until the user interface issues are resolved. I guess changing toolkits is a necessary evil (eg QT4 to QT5, GTK+2 to GTK+3 with GTK+4 already in the wings . . . ). But it uses up a lot of developer time and energy, and the benefits of changing toolkits to the actual purposes for which we use editing software seem to me to be a bit iffy. For a very insightful developer perspective on a comparable change in toolkits, when Krita went from QT4 to QT5, see this link: https://valdyas.org/fading/software/krita-3-0/ Best, Elle On 20 May 2018, at 21:17, Michael Natterer <mi...@gimp.org> wrote: Hi everybody, We just branched: Stable GIMP 2.10.x lives on the new gimp-2-10 branch now. The gtk3-port branch has been merged to master, we're back to normal development in master again. ___ 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] GIMP branched: new stable branch gimp-2-10
On 05/20/2018 04:31 PM, Michael Natterer wrote: On Sun, 2018-05-20 at 21:27 +0200, Carmelo DrRaw wrote: What is the recommended branch for nightly development snapshots? Should one provide snapshots for both master and gimp-2-10? That depends on what you want or what these snapshots are for: gimp-2-10 is where 2.10.x releases are made from. master is bleeding edge. Hopefully related questions (otherwise my apologies for usurping the thread!): I just installed gimp git master on Gentoo without any problems other than updating a couple of dependencies. It even runs :) . git master 2.99/3.0 is where work on porting to GTK3 is happening - will anything else happen in git master for 3.0? Specifically, will changes in handling of brushes and other painting assets (including high bit depth color palettes) be part of 2.10 or 3.0? Is current git master more or less stable for actual use? For context, I started using GIMP-2.9 back in 2013 and from my point of view it was already sufficiently stable. I don't mind the occasional crash (well, assuming the crash doesn't destroy XCF files that aren't actually open for editing). Best, Elle Regards, Mitch On 20 May 2018, at 21:17, Michael Natterer <mi...@gimp.org> wrote: Hi everybody, We just branched: Stable GIMP 2.10.x lives on the new gimp-2-10 branch now. The gtk3-port branch has been merged to master, we're back to normal development in master again. Enjoy! --Mitch ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-devel oper-list List archives: https://mail.gnome.org/archives/gimp-developer-lis t ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-develop er-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 -- Elle Stone https://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] [Gimp-user] Curious about GIMP-2.10 bugs on Windows
On 05/11/2018 10:36 AM, Tom Williams wrote: On 05/11/2018 07:24 AM, Elle Stone wrote: I have no clue whether more people use GIMP on Windows than on Linux. But either way my questions remain: Are most of these "post release of 2.10" bug reports specific to GIMP on Windows? or do they also affect GIMP on Linux? Was there such an influx of Windows(-only?) bug reports for 2.8, compared to 2.10? My initial reaction to the GIMP 2.10 bugs on Windows vs Linux is: have many Linux distros started offering GIMP 2.10 as an upgrade/update? I run Mint 18.3, on my laptop, and GIMP 2.10 isn't available as an update, yet. I don't have the time to try updating GIMP manually, so I wait for the distribution to update the software for me. Now that I think about it, my mom's Ubuntu 16.04 system hasn't received a GIMP 2.10 update either. Maybe as the distros start making GIMP 2.10 available, more Linux users will use it. I'm just thinking out loud. :) OK, that makes sense. Maybe a flood of bug reports from Linux users will come in when/as GIMP-2.10 is included in more Linux distributions. Best, Elle ___ 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] [Gimp-user] Curious about GIMP-2.10 bugs on Windows
On 05/11/2018 10:35 AM, Kevin Payne wrote: On 05/11/2018 09:06 AM, Elle Stone wrote: Are some/many/most of the problems being reported for GIMP-2.10 on Windows, only specific to Windows? Or are these bug reports by Windows users simply bugs that weren't detected by various people running GIMP-2.9/GIMP-2.10-rc/GIMP-2.10 on Linux? I'd suggest that one of the reasons is the relative lack of availability of executables during the 2.9 development phase<https://mail.gnome.org/archives/gimp-user-list> - self compilation not really being an option on Windows. That would explain a lot. Though people do manage to compile GIMP on Windows, it's apparently not easy to do. Partha's 2.9/2.10 builds for Windows have been available for a long time (https://www.partha.com/), without giving rise to nearly so many bug reports as the official release of 2.10. But maybe most Windows users don't know about Partha's builds. Best, Elle ___ 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] Curious about GIMP-2.10 bugs on Windows
On 05/11/2018 09:06 AM, Elle Stone wrote: Are some/many/most of the problems being reported for GIMP-2.10 on Windows, only specific to Windows? Or are these bug reports by Windows users simply bugs that weren't detected by various people running GIMP-2.9/GIMP-2.10-rc/GIMP-2.10 on Linux? Someone sent me a private email in response to my list post, suggesting that more people use Windows, than use GIMP (I don't know if that person actually intended to send a private email or not, so I'm not quoting). I have no clue whether more people use GIMP on Windows than on Linux. But either way my questions remain: Are most of these "post release of 2.10" bug reports specific to GIMP on Windows? or do they also affect GIMP on Linux? Was there such an influx of Windows(-only?) bug reports for 2.8, compared to 2.10? Best regards, -- Elle Stone https://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
[Gimp-developer] Curious about GIMP-2.10 bugs on Windows
Before the release of GIMP-2.10, it seems to me that very few bug reports were filed for GIMP-2.9/2.10 that were specific to Windows. Are some/many/most of the problems being reported for GIMP-2.10 on Windows, only specific to Windows? Or are these bug reports by Windows users simply bugs that weren't detected by various people running GIMP-2.9/GIMP-2.10-rc/GIMP-2.10 on Linux? Context of these questions: Well, mostly I'm just curious. A couple of years ago I subscribed to GIMP bug reports, so I've seen all the bugs filed for GIMP-2.9/GIMP-2.10 for the last couple of years. And since the release of 2.10, it seems like almost all the new bug reports are from Windows users. I didn't see all the bugs filed for GIMP-2.8, neither before nor after the initial release of GIMP-2.8. When GIMP-2.8 was released, were there as many problems with GIMP-2.8 on Windows, as there are with the release of GIMP-2.10? Best, Elle ___ 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] 32 bit float TIFF images without sRGB
On 05/05/2018 05:37 AM, Gonsolo wrote: Hi! I have custom 32 bit float TIFF in linear (HDR) color space. Gimp (2.10) seems to open them with sRGB. Is there a way to disable this or specify another color space? The gamma is especially annoying. Thanks Hi Gonsolo, What are your settings in "Edit/Preferences/Color Management" for Policies regarding "File Open Behavior"? Does your 32-bit floating point tiff have an embedded ICC profile? Best regards, Elle -- Elle Stone https://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
[Gimp-developer] Preferences/Folders/Environment, also Preferences/Folder/Swap vs GEGL_SWAP
Hi, In Preferences, under Folders, what is the Environment folder for? Also, is the "Preferences/Folders/Swap folder" specified in GIMP the same or different from the GEGL swap folder that can be specified using these lines while starting GIMP? GEGL_SWAP=RAM export GEGL_SWAP Best regards, Elle ___ 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] GIMP 2.10-RC1 compile fails
On 04/04/2018 06:53 PM, Umorin, Mikhail P. wrote: Hello — I have configured gimp on MacOS 10.13.4. when I run ‘make’ I get the following error: gimpmybrushcore.c:289:89: error: too few arguments to function call, expected 10, have 8 1.0f /* Pretend the cursor hasn't moved in a while */); ^ /opt/local/include/libmypaint-2.0/mypaint-brush.h:43:1: note: 'mypaint_brush_stroke_to' declared here int ^ gimpmybrushcore.c:325:34: error: too few arguments to function call, expected 10, have 8 dt); ^ /opt/local/include/libmypaint-2.0/mypaint-brush.h:43:1: note: 'mypaint_brush_stroke_to' declared here int ^ 2 errors generated. If you installed libmypaint from git, did you "git checkout v1.3.0"? Elle make[3]: *** [gimpmybrushcore.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Can someone help me figure this out? (I did get the brushes from 1.3.x branch) I appreciate your time Mikhail. ___ 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 -- 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] Motivations/Scopes of the my GIMP 2.10 Brush Set
inishing of the works. Another idea is to promote the .vbr and his editor a the rule more effective for the concept artists and not only. My set could appear a bit large, but I have verified with my friends and artists that are in generally accustomed pick the variation brushes directly from brush palette instead to customize them via his editor... probably this is a gap of our documentation or we need to write tutorials about how effectively to use all instances around the brush on GIMP. Americo's examples of what can be done using a parametric brush are very illuminating. But I somewhat wonder whether a basic brush set needs quite so many versions of the parametric brush, as modifying the vbr brush is incredibly easy. Instead of having 25 "preset parametric brushes" in the basic brush collection, it might be useful to put examples of all the possibilities into a GIMP tutorial, along with a downloadable set customized vbr brushes. And then maybe have only five parametric brushes in the basic brush collection. For my own brush collection, I deleted all except one vbr brush, and just change the softness/size/etc for that one brush as required for the task at hand. The 'B1' folder contains some versions of concept brushes dedicated to emulating the 'real brushes' or brushes with bristles. The 'B2' folder contains the essential set to dry media (pencil, charcoal, chalk) and a new version of hatch pen. *Effects* - contains raster brushes thought to make texture effects in general. I have thought that the term 'effects' is more general and could be used also to aggregate brushes based on raster images dedicated to faux or other exotic effects. *Medium* - is the attempt to conserve the previous and *media* term classification with some interesting stain brushes (static and dynamics). In fact, the criteria for the stains and how we are building this set was modified in function of something more near of real behavior of brushes and tools to draw/paint. In this set, we have some brushes that can emulate some media or techniques but in general the settings on tool options need be more specific... because the generic stains to emulate techniques are much dependent how are configured our settings on Tool Options. *Smudge* - with the new features of smudge tool I have thought necessary create a set specific to use with this tool, normally we can use any brush, but talking with artist as Mozart Couto, Elias da Silva and Gustavo Deveze, I have discovered that each artist has brushes more specific for this usage. So, I have identified the modal behavior of these brushes and I selected brushes of previous set and some new to this scope. The *Legacy* category now is added in a separated category called 'Extras' to implement the default series. In my opinion, the 'Extras' concept is more adequate to solve not only 'legacy' but other additional brushes to complement in future the default set when the artists are interested or when they think necessary. I think useful to create a GitHub account to solve this set. . . . -- Brush Asset Authors Reference Yet is not possible to add info about author and license of each brush, but I have thought that is a good idea, in this moment, add this info directly to the layer of brush. Therefore each brush set of the GIMP 2.10 will be rewritten adding the info of authors in the own brushes, in my opinion, this avoids the necessity of a document with reference of authors to each brush. Until this moment the authors of brush set are: David Revoy Elle Stone GIMP (when was not possible identify the original author). Gustavo Deveze Jag (Americo Gobbo) Johannes Engelhardt Justin W (Akisu-sama) L'ubomir Zabadal Mathias Jonathan Mozart Couto Ramon Miranda Rene Jensen Ulf Worsoe Vallie (valliegurl) Vasco Alexander I don't think I'm the author of any of the brushes :) . I did send Americo an LCH palette and a couple of tool presets including "dynamics/gradient/brush/tool options settings", but the actual brushes were current default GIMP brushes. One preset was for a sketching pencil, and one (which I think I sent) was for a "crayon/chalk pastel" preset, to emulate drawing with the tip (narrow marks) of a crayon/oil pastel/chalk pastel. But I don't have a clue whether these painting assets would be something anyone besides me would find useful. Regarding tagging brushes, here are some suggestions: ** Tagging by size (largest dimension) of brush, which hopefully could be easily generated by GIMP code, broken into convenient groupings such as: extra small approx. 32px or smaller small approx. 64px medium approx. 128px large approx. 256px extra large approx. 512px or larger ** Tagging by type of brush: It would also be convenient to have the type of brush - vbr, gbr, gih - be made into an automatic tag. This way the user could choose to, for example, see "all gbr
Re: [Gimp-developer] ANNOUNCE: GIMP 2.10.0-RC1 released
On 03/26/2018 08:02 PM, Michael Natterer wrote: There is also a release announcement onwww.gimp.org with screenshots of new features: https://gimp.org/news/2018/03/26/gimp-2-10-rc1-released/ At least on my computer, above link leads to 404 page. This link works: https://www.gimp.org/news/2018/03/26/gimp-2-10-0-rc1-released/ Oh, and yeah! 2.10 release candidate! Best, Elle ___ 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] Whether to file bug reports after making several small code modifications?
Hi All, I've been using default babl/GEGL/GIMP for painting for the last several months, instead of using my patched version of GIMP. I switched to using default GIMP for three reasons: * For painting (and probably everything else), default GIMP is faster than my patched version of GIMP. * I really like the new ability to switch between linear and perceptual precision (for example using the new blending/compositing mode options for layers and using Curves/Levels), without having to make an ICC profile conversion. * I want to help debug GIMP code, which is much easier when using default GIMP because I don't have to first replicate in default GIMP a bug or crash that happened in my patched version of GIMP. However, recently I've made some small changes to my default GIMP code that might mean that I shouldn't be filing *any* bug reports: * I reverted the changes that were recently made to the color picking dialogs (https://bugzilla.gnome.org/show_bug.cgi?id=783680). I use an LCH-based color palette when painting, and I always want to see LCH and RGB at the same time. So I reverted these changes. * I find it a bit distracting to have Levels and Curves always load with the last-used settings (https://bugzilla.gnome.org/show_bug.cgi?id=792470). So until this morning I was reverting the relevant Levels and Curves changes (after pulling in the latest GIMP code, my patch to revert these changes no longer works, so I need to make a new patch). * I switched the primaries used by babl/GEGL/GIMP from sRGB to Clay/AdobeRGB, to take better advantage of my monitor's color gamut. Thanks to Pippin's rather awesome new color space code, this seems to only require making very small changes to one babl file (babl/babl-space.c) and two GIMP files (libgimpcolor/gimpcolorprofile.c and libgimpcolor/gimprgb.h). So given the above code changes, should I bother filing new GIMP bug reports or not? These code changes seem "small", but I don't have enough programming savvy to make a decision on this point. Best, Elle ___ 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] GSoC project query
On 03/05/2018 05:29 PM, Jehan Pagès wrote: If you want to contribute ideas, you can add them to the wiki: https://wiki.gimp.org/wiki/Hacking:GSoC/2018/Ideas Please if you do so, if you could add some explanatory links too, that would be awesome, because I would not be able to implement several of your propositions without some serious reading myself. How does one log in to the wiki? I seem to recall from long ago (the one time that I tried to use the wiki) that I ended up logging in as someone else. I don't know what password or user name I might have used, and I don't see a link for creating a new account. I just tried to add a high bit depth unbounded floating point color to a new color palette, and the color was clamped to 8-bit RGB, changing the LCH Hue by 15 degrees! This is a rather large change in color! and rendered my effort to put together an image-specific color palette quite useless. It seems to me that an unbounded floating point RGB image editor at least needs to support unclamped high bit depth RGB color palettes, even if the palettes are "sRGB only" instead of also supporting the color-space-independent LCH, and/or providing a field for specifying the RGB color space primaries. FWIW, I filed a bug report: https://bugzilla.gnome.org/show_bug.cgi?id=794184 Best, Elle ___ 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 make error - Fedora 27
On 03/08/2018 09:58 AM, Partha Bagchi wrote: It says g++ not found. What happens when you type g++ in your GIMP shell environment? Hi Partha - thanks! that was interesting. I didn't have a clue what "g++" might be, but here's what happened when I typed it into a terminal: $ g++ g++: fatal error: no input files compilation terminated. Which seemed mysterious. So I asked Gentoo to tell me which package this "g++" thing was part of: $ equery belongs g++ * Searching for g++ ... sys-devel/gcc-6.4.0-r1 (/usr/x86_64-pc-linux-gnu/gcc-bin/6.4.0/g++ -> x86_64-pc-linux-gnu-g++) I always thought of "gcc" as the "gnu c compiler". But apparently that's no longer the case, instead "gcc" now stands for "gnu compiler collection", which includes c++: https://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/G_002b_002b-and-GCC.html Best, Elle ___ 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] GSoC project query
On 03/05/2018 03:54 PM, Jehan Pagès wrote: Now we have to decide of a good project for GIMP/Darshan since GSoC needs us to decide this first. Note that, as already said previously, I am more in favor of feasible and more concrete projects for GIMP, even though maybe less fancy looking that what we used to have for GSoC. Something which will definitely end up in GIMP in the end.:-) Some suggestions focused on painting and color management: * Better LCH support including high bit depth LCH palettes (to replace current 8-bit sRGB palettes) and gradients, plus for the color pickers outlines showing LCH vs the user-selected RGB color space at any given Lightness value, and showing complements/color harmonies. * Improved soft proofing to compensate for deficiencies in LCMS soft proofing. * Improved painting assets in general, including brushes and brush dynamics, building on Americo's work on improving painting assets, and addressing a bunch of painting-related bug reports. * High bit depth brushes - Cinepaint supported 16-bit brushes, but it would probably be more efficient for GIMP to go straight to 32f brushes. * An HDR viewer and improved HDR editing capabilities. * OCIO color management * Improved support for AnyRGB and AnyTRC. * Adding JCH and CIECAM02 support, following the lead set by RawTherapee's extensive and incredibly useful (for artistic purposes as well as compensating for viewing conditions) CIECAM02 support. Best, Elle ___ 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] Bug reports on PhotoShop "adjustment layers" vs "layer styles"
On 02/06/2018 10:30 AM, Øyvind Kolås wrote: On Tue, Feb 6, 2018 at 4:15 PM, Elle Stone <ellest...@ninedegreesbelow.com> wrote: From the vantage point of "GEGL code in 2018", are the functionalities of PhotoShop "adjustment layers" and "layer styles" similar enough from an implementation point of view that both could be implemented all at once, using the same GEGL code? Or would there need to be substantially different/additional code for layer styles, compared to adjustment layers? Yes - both are non-destructive editing features, and can be impleemnted by inserting additional GeglNodes in the chain/graph of nodes that represent the layer stack. Applying a drop-shadow to the raster output of a part is no different from applying a color adjustment. The live previews done for GEGL based filters in GIMP-2.9 are already done by inserting a temporary one-off adjustment layer on the relevant layer, "inside a layer group". /pippin Pippin - thanks! Best, Elle ___ 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] #gimp irc invitation only?
Hi All, From this page: https://www.gimp.org/irc.html I clicked on this link: irc://irc.gimp.org/#gimp expecting the channel to open using Chatzilla plug-in for Firefox, which is how I've almost always accessed #gimp. What really happened is that Chatzilla presented the following message: [INFO] This channel is invite-only. You must have an invite from an existing member of the channel to join. Use "/knock #gimp" to ask the channel operators to invite you in. [Knock] Any ideas what's going on? Best, Elle ___ 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] Compiling GIMP-2.9 with the new mypaint requirements
On 01/02/2018 08:25 AM, Tobias Ellinghaus wrote: You probably have to add /home/elle/code-install/gimpdefault/install/share/pkgconfig/ to your PKG_CONFIG_PATH. libmypaint installs to lib/pkgconfig and the brushes are in share/pkgconfig. Both are valid locations, but this adds one new path you have to deal with when installing dependencies for GIMP separately. Ah, thanks! I bet that's the problem. I have to do the same thing when installing PhotoFlow to let PhotoFlow knows where to look for libvips. Best, Elle ___ 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] Compiling GIMP-2.9 with the new mypaint requirements
On 01/02/2018 07:38 AM, Elle Stone wrote: When configuring GIMP-2.9, it doesn't find the mypaint brushes. 6. So I tried also install the mypaint brushes in /usr/local, but GIMP still can't find the brushes. 7. In case it's relevant. I have libmypaint-1.3.0 installed from Gentoo portage: equery list '*mypaint*' * Searching for *mypaint* ... [IP-] [ ] media-libs/libmypaint-1.3.0:0/0 Installing the brushes in "/usr" allowed GIMP to find the brushes. But it seems like GIMP should have found the brushes when they were installed in the prefix. Best, Elle ___ 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] Compiling GIMP-2.9 with the new mypaint requirements
When configuring GIMP-2.9, it doesn't find the mypaint brushes. Following this page: https://git.gnome.org/browse/gimp/plain/INSTALL.in 1. I cloned this: git clone https://github.com/Jehan/mypaint-brushes.git 2. I switched to this branch: git branch --list master * v1.3.x 3. I ran these commands: ./autogen.sh --prefix=$PREFIX ./configure --prefix=$PREFIX make && make install 4. I checked to see if the mypaint brushes were installed, and they were. Here are the installed files: /home/elle/code-install/gimpdefault/install/share/mypaint-data/1.0/brushes/. . . (with a bunch of brushes in the brushes folder) /home/elle/code-install/gimpdefault/install/share/pkgconfig/mypaint-brushes-1.0.pc 5. When attempting to configure GIMP, here is the error message: ./autogen.sh --prefix=$PREFIX --with-gimpdir=$PREFIX/config --disable-gtk-doc --enable-debug=yes Error: GIMP configuration failed. - Error: missing dependency mypaint-brushes-1.0 6. So I tried also install the mypaint brushes in /usr/local, but GIMP still can't find the brushes. 7. In case it's relevant. I have libmypaint-1.3.0 installed from Gentoo portage: equery list '*mypaint*' * Searching for *mypaint* ... [IP-] [ ] media-libs/libmypaint-1.3.0:0/0 Did I miss some magic step along the way? If not, how do I tell GIMP where the mypaint brushes are? Best, Elle ___ 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] Show clipped and out of gamut colors using blinking colors
OK, now I'm very puzzled. The Clip Warning shows the exact same pixels as out of gamut, regardless of what RGB color space the image is actually in. Experimenting, it looks like perhaps the clip warning is always determining "out of gamut" with respect to GIMP's built-in sRGB color space, even if the image is in a larger color space and none of the pixels are out of gamut in the larger color space. For example, for a Rec.2020 image opened with default GIMP, none of the colors are out of gamut wrt Rec.2020. But quite a few colors in the highlights (bright saturated yellow-greens - leaves backlit by the sun) have out of gamut colors after converting the image to GIMP's built-in sRGB color space. Is this the case? The clip warning always and only shows colors that are out of gamut wrt to GIMP's built-in sRGB color space? Best, a very puzzled Elle ___ 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] Show clipped and out of gamut colors using blinking colors
On 11/03/2017 10:45 AM, Ell via gimp-developer-list wrote: Yes, the diagonal stripes are basically a static substitute for blinking: it's possible that your image has areas with similar color to the warning color, but it's much less likely that these areas also have a stripe pattern, making the warning more distinguishable. I'm not sure why this would be specifically problematic with small our-of-range areas (though obviously less useful in these cases.) Note that the size of the stripe pattern is independent of the area size, or the zoom level, so, in particular, when you zoom in you can see the pattern over individual pixels. Hi Ell, I just tried the clip warning with an image that I knew had small patches of out of gamut colors - works like a charm! Even for small sprinkles of out of gamut colors - using the tool I found a few pixels in my test image that I didn't already know were out of gamut, but sure enough they were. Best, Elle ___ 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] Show clipped and out of gamut colors using blinking colors
On 11/02/2017 04:21 PM, Ell via gimp-developer-list wrote: On Fri, 20 Oct 2017 09:03:01 -0400 Elle Stone <ellest...@ninedegreesbelow.com> wrote: Hi All, It would be really nice to be able to click a button or have a view module option that would indicate clipped colors by coloring them in some way (perhaps black for shadows, white for highlights), with an option to make these pixels blink. master has a clip-warning display filter now (commit 5b118a260b), which does that. No blinking, though :) Hi Ell, and thank you! That clip warning display filter is really nice! Regarding the blinking, personally I don't much like blinking pixels - probably the only advantage of blinking is to draw attention to very small areas that have out of display range colors. Seeing these areas probably requires zooming in to 100% for just about all image editing softwares, so the blinking per se doesn't seem all that useful. Yesterday when I compiled GIMP the new filter was there, but nothing was happening on the image - not sure why. But today I updated GIMP again, and recompiled, and made an image that was a gradient from -1.0f to +2.0f. The gradient ran from the upper left to the lower right corner. The Clip Warning shows diagonal parallel red and black bars for the highlights, and diagonal parallel blue and black bars for the shadows. Are there supposed to be diagonal bars instead of solid blotches of the user-chosen warning colors? If so, how would this work with images with just speckles and very small areas of out of display range colors? I'll try to do some more experimenting later on today. The option to choose the clipping warning colors is really nice, allows to choose different default colors, and also to change the warning colors for images that actually have a lot of in-gamut colors that are displayed close to the preset colors. Best, and again thank you! The new clip warning was such a nice surprise! Elle ___ 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] Tuning and choosing resampling methods in GEGL/GIMP
On 10/23/2017 10:03 AM, Øyvind Kolås wrote: This is what an adaptively increasing the OFFSET0 constant for significant downscaling in the sources might achieve - do note that what is meant by significant downscaling here is when scaling down to below 1% of original size - even in such scenarios nohalo will already be doing a good job. OK, that sounds less scary than the commit message! As an aside, with today's high-pixel-count cameras, we are already at the point where resizing an image for display on the web might get the downscaling somewhat close to 1%. Resizing a 6000px wide image to 600 pixels - that's 10% for a 24 megapixel camera, and there are cameras with much larger sensors out there. I believe that even without further enhancement we should use nohalo as the default sampler. Normally I only resize single-layer images, or at most images with a few layers, so the speed of nohalo hasn't been a concern, and I do have nohalo set as the default. But there are cases when users will want to operate on large layer stacks. Is the revised version of nohalo fast enough to handle a large image size with a lot of layers, even for various transforms? There doesn't seem to be a cancel button for various transformations for cases where users might not have checked the default settings before setting in motion a tranform that will take a long time. Best, Elle ___ 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] Tuning and choosing resampling methods in GEGL/GIMP
On 10/23/2017 09:13 AM, Øyvind Kolås wrote: The actual reason for this email is that I think it might be overkill to have both lohalo and nohalo available as choices, they are related and powerful transformation ellipsis aware methods, maybe it is sufficient to have one go-to high quality resampler instead of expecting the user to make a choice between lohalo and nohalo on a case by case or built up as general preference, and in which case I believe of these two related methods, from Nicolas Robidoux & collaborators, we'd be best off keeping the nohalo method - possibly with an adaptive _OFFSET0 to speed resampling that is primarily interpolatory. Hi Pippin, Agreeing with what you say, I've tried lohalo and never saw any reason to use it instead of nohalo. For several years now nohalo is the only downsizing method that I use. I see in the git log that some changes have been made recently to nohalo. I haven't used the new version of nohalo, and also haven't added these changes to my "CCE" version of GIMP. The reason I mention this is because even though nohalo (the older version of nohalo) is slow, it produces results that are exceptionally good. The recent GEGL commit 0b0ecbb67198d6318ed163522e5233ecbc18ff25 mentions slightly sharper results for nohalo: "for sigificant downsampling this might result in sharper/aliased results". This "sharper/aliased results" doesn't sound like a good thing, at least not for my particular workflow. I don't use a lot of sharpening in my workflow, and I prefer to do any required post-downsizing sharpening by hand, using masks and layers, and using either unsharp mask or high pass sharpening, on an image by image basis. Would there be the possibility of parameters with the revised nohalo that would allow to replicate the old results? Best, Elle ___ 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] Show clipped and out of gamut colors using blinking colors
On 10/20/2017 09:18 AM, Alexandre Prokoudine wrote: On Fri, Oct 20, 2017 at 4:03 PM, Elle Stone wrote: http://gimp.1065349.n5.nabble.com/GIMP-2-9-useability-out-of-gamut-and-HDR-channel-values-td45195.html#a45198 - there was a suggestion that this functionality already exists, but if it does, I can't find it :) . Color managements prefs Alex Hi Alex, Do you mean the "Mark out of gamut colors" option under soft proofing? That would only work if the following were true: 1. The user picked the current editing color space as the color space for soft proofing. 2. LCMS soft proofing would need to show out of gamut colors when the source and destination color space have the same bounded color gamut, which currently is not the case. Leastways right now I'm looking at an image with hugely out of gamut channel values, with the appropriate soft proofing settings in Preferences. Not a single pixel is marked as out of gamut. 3. For cases where the user has chosen linear precision, LCMS soft proofing would need to work properly for linear RGB, which currently is not the case. As an aside, for using LCMS for soft proofing and gamut checks, it would be better if the RGB values sent to LCMS were at "perceptual precision", regardless of what precision the user has chosen. Even if LCMS soft proofing changed in the future, the gamut check doesn't differentiate between clipped/oog shadow colors and clipped/oog highlight colors. Using LCMS to check for out of gamut colors does slow down the speed at which GIMP can display changes in the image made while editing. Also going into Preferences is a bit cumbersome for something the user might not want to leave permanently activated. Buttons/checkboxes similar to what the raw processors use would be very much more convenient. Elle ___ 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] Show clipped and out of gamut colors using blinking colors
Hi All, It would be really nice to be able to click a button or have a view module option that would indicate clipped colors by coloring them in some way (perhaps black for shadows, white for highlights), with an option to make these pixels blink. UFRaw, darktable, RawTherapee, PhotoFlow all provide this functionality via buttons on a bar below the image. In GIMP, maybe the status bar would be a good location. This topic was briefly mentioned on the gimp dev list back in April 2015. There are two open bug reports. Also the question came up today on the pixls.us forum: https://discuss.pixls.us/t/clipped-pixels/5394 https://bugzilla.gnome.org/show_bug.cgi?id=316355 https://bugzilla.gnome.org/show_bug.cgi?id=316356 http://gimp.1065349.n5.nabble.com/GIMP-2-9-useability-out-of-gamut-and-HDR-channel-values-td45195.html#a45198 - there was a suggestion that this functionality already exists, but if it does, I can't find it :) . Best, Elle ___ 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] Odd "error making format" regarding grayscale ICC profiles
On 10/10/2017 06:49 AM, Øyvind Kolås wrote: These messages are debug messages, informing us that GIMP tried to create dedicated babl_formats from the ICC profiles, babl detected that it is a type of ICC profile it is not capable of handling, thus GIMPs attempt at creating a babl based format (and thus conversions) failed. GIMP will then instead use lcms2 for conversions to/from the color space of the ICC profile. Hi Pippin, Thanks! -what you describe is what I assumed was happening :) . But I was puzzled about these error/warning messages also being printed when adding a layer mask to an RGB image. Are the babl ICC code and/or LCMS used to make layer masks in GIMP? Whether or no, the masks are made without any problems. Best, Elle ___ 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] something wrong with healing brush
On 10/06/2017 02:26 AM, Alexander Rabtchevich wrote: Hello It seems healing brush is broken. It produces artifacts and the result is not as before. I guess it happened when color transform code was involved, but that's only a supposition. See this bug report: https://bugzilla.gnome.org/show_bug.cgi?id=783755 The healing tool uses Subtract to calculate color differences, which only produces expected results when using RGB encoded more or less perceptually. But using Subtract on perceptually uniform RGB does produce obvious gamma artifacts in extreme cases that maybe would never come up in normal editing. Regardless of the extreme cases, if Subtract is used to calculate color differences, the healing tool should use perceptually uniform RGB. But instead of using Subtract, it might be better to use LAB to calculate color differences. Best, Elle ___ 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] Size on disk vs size reported on status bar
On 10/04/2017 09:02 AM, Jehan Pagès wrote: Hi! On Wed, Oct 4, 2017 at 2:28 PM, Jehan Pagès <jehan.marmott...@gmail.com> wrote: Hi again! On Wed, Oct 4, 2017 at 1:01 PM, Elle Stone <ellest...@ninedegreesbelow.com> wrote: Actually the image is at 32-bit floating point precision, all the layers have alpha channels, most of the layers have masks, and there are a couple extra channels (saved masks) in the channels dialog. Ignoring the masks and the extra saved channels, and assuming I'm doing the right math, this would be: 4000*6000*7*32*4 = 21 504 000 000 / 1024^3 ~ 20 GB Sorry I was stupid earlier. By multiplying by 24 (or here 32), we get the size in bits, we want in bytes (instead, we must multiply by 3 bytes for 32 bits). So a single mono-channel image should be 4000*6000*3 bytes. So assuming each layer has alpha and mask, that makes 5 channels per layer and each channel uses 3 bytes: 4000*6000*3*7*5 ~ 2.34 GB. Ok so I meant 4 bytes of course! I can't even do basic maths right anymore! :P 4000*6000*4*7*5 ~ 3.2G. Hi Jehan, So a byte is 8 times a bit? For people like me who can never remember the difference between a byte and a bit, is there a one-sentence explanation for why there are bytes *and* bits? Ok so I had a quick look at the code. For the size displayed in the status bar, it seems it would use the size as returned by each GimpObject through the get_memsize() virtual method: https://git.gnome.org/browse/gimp/tree/app/core/gimpobject.c#n445 You can get an idea of the expected size by looking at GimpTemplate code which is used to guess the future memory size (to warn before image creation if the expected size will be big): https://git.gnome.org/browse/gimp/tree/app/core/gimptemplate.c#n426 We can see that the expected size seems to be based on the initial layer + the selection + the projection (which apparently always has alpha and multiplies the result by 1.33: https://git.gnome.org/browse/gimp/tree/app/core/gimpprojection.c#n326). So for your image with 7 layers, alpha (and assuming all with mask), following this estimation algorithm: 4000*6000*4*7*5 + 4000*6000*4 + 4000*6000*16*1.33 ~ 3.7GB. This estimation is quite close to the actual 3.8GB GIMP gives you. With the few more channels you said you had, I guess that's about it. :-) Thanks! That's a nice explanation! This might be useful to put in the user's manual, if it isn't already there. Best, Elle ___ 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] Size on disk vs size reported on status bar
On 10/03/2017 09:40 PM, Jehan Pagès wrote: Hi again! On Tue, Oct 3, 2017 at 8:18 PM, Elle Stone <ellest...@ninedegreesbelow.com> wrote: On 10/03/2017 01:21 PM, Simon Budig wrote: The current generation XCF files can contain compressed image data. When I save XCF files I don't use the option in the Save dialog to compress the data. Is there some other compression going on automatically? Yes, XCF historically uses RLE compression, which is basic hence not great, but still enough for a very simple image with a lot of identical (i.e. same color) adjacent pixels (as I understand your image is). The option in the save dialog is about activating the newer zlib compression instead, which is much more sophisticated and should therefore result in even smaller files. But on very simple files, simple compression can work great too (sometimes even better than complex compression, that's rare but it may happen). Hi Jehan, Thanks! for this information. I didn't realize any compression was being used if the option in the save dialog wasn't selected. Saving large files can take a long time. Does anyone know how much time percent-wise is literally writing the file out (well, I suppose this would partly depend on the type of disk and the file system type), versus how much time is spent doing the compression before the file is written? How large would the XCF file would be if there were no compression at all before writing the file to disk, compared to the compressed size? Best, Elle ___ 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] Size on disk vs size reported on status bar
On 10/03/2017 09:33 PM, Jehan Pagès wrote: I don't know how this info is computed in GIMP code (i.e. does it check for actual memory size or does it do some basic maths as I am about to do), but assuming your image is 8 bits per channel, and all 7 layers are the size of the image and have no alpha, that makes: 4000*6000*7*24 = 4 032 000 000 / 1024^3 ~ 3.8GB!:-) Hi, Actually the image is at 32-bit floating point precision, all the layers have alpha channels, most of the layers have masks, and there are a couple extra channels (saved masks) in the channels dialog. Ignoring the masks and the extra saved channels, and assuming I'm doing the right math, this would be: 4000*6000*7*32*4 = 21 504 000 000 / 1024^3 ~ 20 GB As an experiment, I followed Simon's suggestion and made a new document, same size, 7 layers, and filled each layer with random LCH noise. This brought the %m value up to 4.8 GB. Removing all operations from the Undo history brought the %m value down to 2.9 GB. Saved to disk, the size is 1.6 GB. I guess random noise also compresses? Best, Elle ___ 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] Size on disk vs size reported on status bar
On 10/03/2017 01:21 PM, Simon Budig wrote: The current generation XCF files can contain compressed image data. When I save XCF files I don't use the option in the Save dialog to compress the data. Is there some other compression going on automatically? Best, Elle ___ 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] Painting on a text layer, turning it into a regular layer?
I wasn't actually trying to paint on a text layer. But I had inadvertently selected a text layer when I used the brush tool, and the text disappeared under the paint. Is this new behavior? This is from babl/GEGL/GIMP from git updated this morning (commit 188a82552b). I'm kind of hoping this is a bug and not the actually intended behavior. Best, Elle ___ 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] plug-ins/file-jpeg : Segmentation fault
On 01/29/2017 07:51 AM, Helmut Jarausch wrote: On 01/28/2017 08:28:34 PM, Elle Stone wrote: FWIW, here is how I build babl/GEGL/GIMP from git: http://ninedegreesbelow.com/photography/build-gimp-in-prefix-for-artists.html What prefix are you installing babl/GEGL/GIMP from git in? I have my own ebuilds and they install into /usr One thing that sometimes helps is to completely uninstall all versions of babl/GEGL/GIMP (even the portage versions). Then in the prefix for babl/GEGL/GIMP from git, delete and recreate the install folder, so there's nothing left behind to interfere with a fresh install. And also do "git clean -xdf" to get the build folders completely clean. And then start installing from scratch. I've done that but the problem persists The only other thing that comes to mind is whether your libraries for jpeg, png, and tiff are all too old. I have media-libs/libjpeg-turbo-1.5.1 media-libs/libpng-1.2.57 media-libs/tiff-4.0.7 Just for reference, here's what I have: media-libs/tiff-4.0.7 media-libs/libjpeg-turbo-1.5.0 media-libs/openjpeg-2.1.2 media-libs/libpng-1.6.27 I'm not sure whether GIMP uses lib-jpeg-turbo or openjpeg. But maybe installing openjpeg would help. As we both have the same version of tiff installed, outdated libraries probably aren't the only problem, or else you would be able to export a tiff. Your libpng is too old - I'm a bit surprised that recently pulled GIMP-2.9 builds at all given the older version of libpng. Do you have a hint on how to debug my problem? Any problem that results specifically from an ebuild, no, I'm clueless. You could try building in a prefix as per my "how to build" article and see if you still have a problem exporting files. Did you try using the "--enable-debug=yes" option when running autogen.sh, and then running GIMP under gdb? I saw your stack trace but it didn't seem helpful, well, imho they often aren't. Beyond that, no, my apologies, I'm not very experienced at debugging code. Oh, wait, looking at your stack trace again, it seems a bit odd that there is all this stuff about tiff when you are trying to output a jpeg. I've seen problems where there is interference between a GIMP plug-in for opening a raw file and the GIMP code for opening a tiff (http://gimp.1065349.n5.nabble.com/Darktable-plug-in-in-GIMP-td47681.html#a47692). Elle ___ 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] plug-ins/file-jpeg : Segmentation fault
On 01/28/2017 12:02 PM, Helmut Jarausch wrote: On 01/27/2017 07:01:47 PM, Elle Stone wrote: On 01/27/2017 12:06 PM, Helmut Jarausch wrote: is it only me (or my system) that the current GIT version (2017/01/27 17:27 GMT) dies of a segmentation fault whenever I try to "export as" JPEG. On Gentoo Linux, GIMP-2.9 updated from git just now and rebuilt, exporting a jpeg works normally. Unfortunately Gimp crashes here (Gentoo, as well) each time I try to export an image to any format (I've tried jpeg png tiff). This occurs with version 2.9.4-r1 (here on Gentoo) as well as with the GIT version. It seems odd that you can't export using any file format. FWIW, here is how I build babl/GEGL/GIMP from git (I don't follow the "gentoo way" of installing software from source): http://ninedegreesbelow.com/photography/build-gimp-in-prefix-for-artists.html What prefix are you installing babl/GEGL/GIMP from git in? Is it possible that 2.9.4 from portage is interfering with GIMP installed in the prefix? One thing that sometimes helps is to completely uninstall all versions of babl/GEGL/GIMP (even the portage versions). Then in the prefix for babl/GEGL/GIMP from git, delete and recreate the install folder, so there's nothing left behind to interfere with a fresh install. And also do "git clean -xdf" to get the build folders completely clean. And then start installing from scratch. The only other thing that comes to mind is whether your libraries for jpeg, png, and tiff are all too old. But that seems unlikely if you are running Gentoo. Best, Elle ___ 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] plug-ins/file-jpeg : Segmentation fault
On 01/27/2017 12:06 PM, Helmut Jarausch wrote: is it only me (or my system) that the current GIT version (2017/01/27 17:27 GMT) dies of a segmentation fault whenever I try to "export as" JPEG. On Gentoo Linux, GIMP-2.9 updated from git just now and rebuilt, exporting a jpeg works normally. Elle ___ 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] Reporting bugs for 2.9.5?
On 01/11/2017 12:40 PM, Thorsten Stettin wrote: Dear Developers, I'm going slightly mad. Why do you need libpng >= 1.6.25, and lcms2 >= 2.7 in order to build Gimp 2.9.5 - commit 36ebe03770fd8b87102e95cd6c45b194a45a8ba3? libpng: https://bugzilla.gnome.org/show_bug.cgi?id=765850 lcms: https://bugzilla.gnome.org/show_bug.cgi?id=736701 Best, Elle ___ 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] Bug reports that would be nice to see on the milestone 2.10 list
Your wish is my command, she said responding to IRC! A compact list: * No LCH color pickers and no LCH Hue-Chroma tool (https://bugzilla.gnome.org/show_bug.cgi?id=749902) * No Luminance blend mode (https://bugzilla.gnome.org/show_bug.cgi?id=753163). * No easy way to make Curves and Levels adjustments on linear RGB (https://bugzilla.gnome.org/show_bug.cgi?id=757444) * No obvious way to invert colors on linear RGB (https://bugzilla.gnome.org/show_bug.cgi?id=757686). * No easy way to draw a gradient using linear RGB (https://bugzilla.gnome.org/show_bug.cgi?id=735897). * No easy way to correctly decompose to LAB/LCH and then be able to drag layers back to the layer stack (https://bugzilla.gnome.org/show_bug.cgi?id=765178. * No easy way to correctly extract LAB/LCH channels as layers (https://bugzilla.gnome.org/show_bug.cgi?id=755376). Best, Elle ___ 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] Bug reports that would be nice to see on the milestone 2.10 list
There are some bug reports listed below that pertain to color management and color mixing, that I would very much like to see be put on the "milestone 2.10" list. Here's why: I just posted a tutorial on using GIMP to make an illustration from a photograph: http://ninedegreesbelow.com/photography/leaves-in-may-illustration-from-photograph.html If you look at the articles on my website (http://ninedegreesbelow.com/photography/articles.html), there are a bunch of articles on using high bit depth GIMP, because high bit depth GIMP is my favorite image editor ever, hands down more useful than PhotoShop ever was (though I dearly miss having adjustment layers). Personally I don't use default GIMP 2.9 for editing, but rather a patched version of GIMP (http://ninedegreesbelow.com/photography/patched-gimp-compared-to-default-gimp.html). When I write a tutorial on using GIMP, I try to include information on using default GIMP as well as my patched version of GIMP. But I keep running into the same problems with trying to edit using default GIMP: * No LCH color pickers and no LCH Hue-Chroma tool (https://bugzilla.gnome.org/show_bug.cgi?id=749902) * No Luminance blend mode (https://bugzilla.gnome.org/show_bug.cgi?id=753163). * No easy way to make Curves and Levels adjustments on linear RGB (https://bugzilla.gnome.org/show_bug.cgi?id=757444) * No obvious way to invert colors on linear RGB (https://bugzilla.gnome.org/show_bug.cgi?id=757686). * No easy way to draw a gradient using linear RGB (https://bugzilla.gnome.org/show_bug.cgi?id=735897). * No easy way to correctly decompose to LAB/LCH and then be able to drag layers back to the layer stack (https://bugzilla.gnome.org/show_bug.cgi?id=765178 - also affects my patched GIMP, except I disabled decompose altogether for unrelated reasons). * No easy way to correctly extract LAB/LCH channels as layers (https://bugzilla.gnome.org/show_bug.cgi?id=755376 - also affects my patched GIMP). If the above issues were fixed, then default GIMP would be very useable for following the steps in my tutorials as long as the user sticks with the built-in sRGB color space. And I could go through my tutorials and remove passages like "here's the workaround for default GIMP", "here's how to get the right LAB/LCH layers", "the workaround for default GIMP is too complicated to explain in this tutorial", and so forth. And then I think the only remaining major advantage my patched GIMP would have over default GIMP would be the ability to edit in user-chosen RGB working spaces. Well, that and I've unclamped a few additional blend modes and etc, to make some VFX people happy (and this unclamping turns out to be useful for general editing). Going beyond the fact that I'd really like to rewrite my GIMP tutorials to sound less critical of default GIMP, the above-listed bug reports fall into three fairly important categories: 1. Allow GIMP users to take full advantage of LCH blend modes, which is something I don't think any other image editors yet provide. 2. Allow GIMP users to produce radiometrically correct results for editing operations that affect tonality. Right now GIMP users get gamma artifacts every time they use Levels or Curves or invert colors, and they have to resort to workarounds to draw a linear gamma gradient. For an image editor that purports to make radiometrically correct editing results easy to produce, this is an unfortunate situation. 3. Fix GIMP's handling of LAB/LCH decompose and GEGL's extract component, so that GIMP users will be able to use LAB/LCH layers and actually get correct results from drag and drop and such. I realize that developer time is limited, and of course I'm willing to help update and test patches for the above bug reports. I also realize that everyone thinks their own bugs are "the most important", and perhaps I'm overestimating the importance of the above bugs (but I don't think I am). But like I said, I keep running into the same issues every time I try to use default GIMP, so I thought I'd at least make a post on the subject. Best, Elle -- 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
[Gimp-developer] New Advanced Color options in the UIs for various operations
The following code snippet is from default GIMP's
"app/tools/gimpfiltertools.c" file. It's been added sometime relatively
recently.
Could someone please explain what this new code is supposed to mean/do?
/* The color managed combo */
combo = gimp_prop_boolean_combo_box_new
(G_OBJECT (tool_info->tool_options), "color-managed",
_("Apply filter in color managed space (slow)"),
_("Apply filter to the layer's raw pixels"));
gtk_box_pack_start (GTK_BOX (vbox2), combo, FALSE, FALSE, 0);
gtk_widget_show (combo);
The above code is reflected in the "Advanced Color Options" for tools
such as Levels, Curves, Saturation, and Gaussian Blur. The user has to
click the "+" to see the hidden options. Putting aside the gamma hack
option, the other option provides two possibilities:
1. "Apply filter to the layer's raw pixels"
2. "Apply filter in the color managed space (slow)".
The option to "Apply filter to the layer's raw pixels" seems to be the
default, but I'm not sure.
What's the difference between these two options? I mean conceptually and
also in the code paths that are taken?
I've tried using both options for several editing operations, including
Levels, GEGL Saturation, and Gaussian Blur, and for images in the
built-in sRGB working space I don't see any difference at all in the
resulting image, whether working at "linear" or "gamma" precision (not
the gamma hack, rather "Image/Precision").
When using the GEGL Saturation operation, if I chose the "Apply filter
in the color managed space (slow)" option, this message was printed to
the terminal:
filter format: CIE Lab float
(gimp-2.9:30663): Gimp-GEGL-CRITICAL **: file gimp-babl.c: line 547
(gimp_babl_format_get_base_type): should not be reached
(gimp-2.9:30663): Gimp-GEGL-CRITICAL **: file gimp-babl.c: line 648
(gimp_babl_format_get_linear): should not be reached
When at gamma precision, and assigning a linear gamma profile from disk
to the test image, and doing a Gaussian blur, choosing one or another of
"Apply filter to the layer's raw pixels" and "Apply filter in the color
managed space (slow)" did produce a difference in the preview, but both
previews were wrong.
So I'm very puzzled as to what this new advanced option is supposed to
do. Any light on the matter would be greatly appreciated.
Best,
Elle
___
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] High bit depth assets to GIMP 2.10
On 10/23/2016 09:57 AM, Elle Stone wrote: On 10/22/2016 08:50 PM, Americo Gobbo wrote: Hi All, Is possible discuss again the possibility to have assets in 16 and 32 bit, mainly the palettes and patterns. On the topic of high bit depth assets, it would also be nice if the color sliders for picking colors would read out high bit depth values, either always floating point, or else as appropriate to the bit depth of the image. Eigh-bit integer color sliders for picking colors just isn't enough precision for working with high bit depth images. Twice I've tried to modify the relevant code, but failed because I couldn't figure out how to get past the part of the code that seems to use the size of the box to relate slider movements to the RGB values. All the relevant code uses guchar variables. Elle ___ 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] High bit depth assets to GIMP 2.10
On 10/22/2016 08:50 PM, Americo Gobbo wrote: Hi All, Is possible discuss again the possibility to have assets in 16 and 32 bit, mainly the palettes and patterns. The initial discussion was proposed by Alexandre Prokoudine, in 2014 > https://mail.gnome.org/archives/gimp-developer-list/2014-February/msg00050.html That's an interesting discussion. Here's a link to the Nabble archive (makes it easier to read the entire thread): http://gimp.1065349.n5.nabble.com/assets-in-the-high-bith-depth-age-td41929.html I would very much like to see palettes and such stored using 32f floating point LCH rather than 8-bit RGB, for two reasons: 1. Eight-bit precision is insufficient precision for storing linear gamma color information - darker colors are severely posterized upon being saved to disk, to the point where the human eye can see that the color has changed. 2. LCH is independent of the RGB color space, which means "color managing" the LCH assets is a matter of converting from the stored LCH values to whatever RGB working space the user happens to be using. Which for GIMP 2.10 really should be sRGB, but as indicated by the Roadmap for future versions of babl/GEGL/GIMP this will change. Has Krita moved on past the 8-bit assets? If so what is Krita using to store palettes and such? 16-bit integer would be enough to store "more precision than the eye can see", but wouldn't allow to store colors that are outside the display range, whereas high bit depth GIMP's (rather babl's, with supporting unclamped operations in GEGL and GIMP) RGB/XYZ/LAB/LCH color conversions do allow to calculate and store out-of-display-range colors. Elle ___ 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
