GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2024-03-27T20:19:29Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/35Outlined text2024-03-27T20:19:29ZBugzillaOutlined text## Submitted by jky..@..ja.net
**[Link to original bug (#102822)](https://bugzilla.gnome.org/show_bug.cgi?id=102822)**
## Description
It would be nice to be able to produce text with an outline. I guess that X
doesn't directly sup...## Submitted by jky..@..ja.net
**[Link to original bug (#102822)](https://bugzilla.gnome.org/show_bug.cgi?id=102822)**
## Description
It would be nice to be able to produce text with an outline. I guess that X
doesn't directly support drawing characters with borders.
A quick hack would be to do something like:
alpha to selection -> stroke
after the text is rendered. I have modified the gdyntext plugin to do this (using
the current brush)
I haven't thought of the UI part yet. For sure, a toggle is needed. Another thing
could be a brush selector or a thickness value. Possible issues with antialiasing?
Version: git master
### Blocking
* [Bug 136740](https://bugzilla.gnome.org/show_bug.cgi?id=136740)2.99.14https://gitlab.gnome.org/GNOME/gimp/-/issues/23Entering large dimensions in Scale Image causes fatal error2024-03-27T20:19:28ZBugzillaEntering large dimensions in Scale Image causes fatal error## Submitted by asc..@..sf.edu
**[Link to original bug (#78064)](https://bugzilla.gnome.org/show_bug.cgi?id=78064)**
## Description
Entering large values (like 2000000) for both horizontal (X) and
vertical (Y) ratios with percent m...## Submitted by asc..@..sf.edu
**[Link to original bug (#78064)](https://bugzilla.gnome.org/show_bug.cgi?id=78064)**
## Description
Entering large values (like 2000000) for both horizontal (X) and
vertical (Y) ratios with percent mode in the Scale Image dialog
causes a fatal bus error a short time after clicking OK. This occurred
with a new, blank image window sized 256 pixels by 256 pixels.
Version: 1.x
### Depends on
* [Bug 21028](https://bugzilla.gnome.org/show_bug.cgi?id=21028)https://gitlab.gnome.org/GNOME/gimp/-/issues/11Some plug-in settings should be persistent accross sessions2024-03-27T20:19:28ZBugzillaSome plug-in settings should be persistent accross sessions## Submitted by Raphaël Quinet
**[Link to original bug (#63610)](https://bugzilla.gnome.org/show_bug.cgi?id=63610)**
## Description
It would be nice if there was a way to save some settings for the plug-ins
(especially the file_save...## Submitted by Raphaël Quinet
**[Link to original bug (#63610)](https://bugzilla.gnome.org/show_bug.cgi?id=63610)**
## Description
It would be nice if there was a way to save some settings for the plug-ins
(especially the file_save plug-ins) so that they become the new defaults
for the next invocation of the plug-in. Currently, these settings are
preserved during the current session, but they are lost when you exit and
restart the Gimp.
This should be optional because in most cases it is better to go back to
the hardcoded defaults whenever the Gimp starts. But sometimes these
defaults are not optimal and it would be nice to have a way to change them.
For example, there could be a "Save Default Options" button in all plug-ins
that can be called interactively.
Version: 1.x
### Depends on
* [Bug 470459](https://bugzilla.gnome.org/show_bug.cgi?id=470459)
### Blocking
* [Bug 81015](https://bugzilla.gnome.org/show_bug.cgi?id=81015)
* [Bug 101604](https://bugzilla.gnome.org/show_bug.cgi?id=101604)
* [Bug 120829](https://bugzilla.gnome.org/show_bug.cgi?id=120829)
* [Bug 734656](https://bugzilla.gnome.org/show_bug.cgi?id=734656)
### See also
* [Bug 599573](https://bugzilla.gnome.org/show_bug.cgi?id=599573)2.99.2https://gitlab.gnome.org/GNOME/gimp/-/issues/3cancelling a plug-in may leave dangling images around2024-03-27T20:19:27ZBugzillacancelling a plug-in may leave dangling images around## Submitted by kel..@...in.us
**[Link to original bug (#8141)](https://bugzilla.gnome.org/show_bug.cgi?id=8141)**
## Description
Package: gimp
Cancelling the warp plugin sometimes leaves the temporary images
created to hold the di...## Submitted by kel..@...in.us
**[Link to original bug (#8141)](https://bugzilla.gnome.org/show_bug.cgi?id=8141)**
## Description
Package: gimp
Cancelling the warp plugin sometimes leaves the temporary images
created to hold the displacement maps laying around.
Kelly
------- Additional Comments From sven@gimp.org 2000-12-09 12:29:15 ----
Subject: Re: cancelling warp plugin leaves tmp displacement map images around
From: Sven Neumann <sven@gimp.org>
To: 8141@bugs.gnome.org
Message-Id: <87hf4dtses.fsf@gimp.org>
Date: 09 Dec 2000 18:29:15 +0100
Hi,
I'm afraid we can not easily do something about this problem with the
current design of plug-ins in the gimp. The plug-in would need to register
a quit function that aborts the running calculation, then cleans up. Since
Gimp gives us only 10 ms before it kills the plug-in after sending quit
through the pipe, it would be very difficult to implement this properly.
I'll set severity of this bug-report to wishlist.
Salut, Sven
------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:50 -------
This bug was previously known as [bug 8141](https://bugzilla.gnome.org/show_bug.cgi?id=8141) at http://bugs.gnome.org/
http://bugs.gnome.org/show_bug.cgi?id=8141
Originally filed under the gimp product and general component.
The original reporter (kelly@poverty.bloomington.in.us) of this bug does not have an account here.
Reassigning to the exporter, debbugs-export@bugzilla.gnome.org.
Reassigning to the default owner of the component, egger@suse.de.
Version: git masterhttps://gitlab.gnome.org/GNOME/gimp/-/issues/359"Color Range Mapping" plug-in missing since 2.42024-03-23T17:29:39ZBugzilla"Color Range Mapping" plug-in missing since 2.4## Submitted by Owen Swerkstrom
**[Link to original bug (#641893)](https://bugzilla.gnome.org/show_bug.cgi?id=641893)**
## Description
Created attachment 180434
patch with upgraded plug-in
This plug-in was extremely useful and its ...## Submitted by Owen Swerkstrom
**[Link to original bug (#641893)](https://bugzilla.gnome.org/show_bug.cgi?id=641893)**
## Description
Created attachment 180434
patch with upgraded plug-in
This plug-in was extremely useful and its functionality is not available in any existing plug-in. The old plug-in no longer loads in newer versions of GIMP, either.
So, I dug up the old code and did some refactoring and cleanup. A shiny new version of the plug-in now builds and runs happily, restoring functionality I and many others have been sorely missing for a while now.
If there are any objections at all to this patch, please email me; I will bend over backwards to get this feature back. Just tell me what to do.
**Patch 180434**, "patch with upgraded plug-in":
[0001-added-back-an-updated-version-of-the-color-range-map.patch](/uploads/db1d212be979657307cbf705d2e63cd2/0001-added-back-an-updated-version-of-the-color-range-map.patch)
Version: git masterhttps://gitlab.gnome.org/GNOME/gimp/-/issues/594Replace hard-coded sRGB parameters to allow editing in other RGB working spaces2024-03-22T23:50:59ZBugzillaReplace hard-coded sRGB parameters to allow editing in other RGB working spaces## Submitted by Elle Stone `@ellestone`
**[Link to original bug (#737778)](https://bugzilla.gnome.org/show_bug.cgi?id=737778)**
## Description
Created attachment 287578
Patch to retrieve the user-chosen RGB working space parameters....## Submitted by Elle Stone `@ellestone`
**[Link to original bug (#737778)](https://bugzilla.gnome.org/show_bug.cgi?id=737778)**
## Description
Created attachment 287578
Patch to retrieve the user-chosen RGB working space parameters.
Currently some GIMP editing operations are hard-coded to use parameters specific to sRGB. To allow correct editing in other RGB working spaces, the hard-coded sRGB parameters must be replaced with parameters retrieved from the image's actual RGB working space.
Problems with forcing a conversion to unbounded sRGB and keeping the hard-coded sRGB parameters include:
1. Multiply produces different results in different RGB working spaces (http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb).
2. Adding and removing color casts (changing the image white balance) involves multiply, so color casts that were created in some other RGB working space cannot be easily corrected in the sRGB working space (http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html).
3. Using sRGB colorants to encode colors that are outside the very small bounded sRGB color gamut requires using negative channel values. Multiplying and dividing colors that are encoded using negative channel values produces physically meaningless results (http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html).
4. Over 50% of the core GIMP editing operations that I checked are chromaticity dependent, giving different results in different RGB working spaces (http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html#chromaticities-matter). Any editing operation that involves multiply, divide, or raising RGB values to a power produces different results in different RGB working spaces. Only the artist can say which working space gives the best results. Therefore a forced conversion to sRGB severely compromises artistic freedom.
5. Converting an image from one RGB working space to another rearranges channel data, sometimes making it unuseable. Therefore a forced converstion to unbounded sRGB severely limits the artist's ability to make creative use of channel data.
6. Standard display-referred image editing requires using RGB channel values that are encoded using RGB channel values that are clipped to the RGB floating point range 0.0 to 1.0, inclusively. Trying to perform display-referred edits on colors that are encoded using negative channel values and/or channel values that are greater than 1.0 produces meaningless results. Consequently display-referred image editing is flatly broken in the unbounded sRGB color space (http://ninedegreesbelow.com/photography/display-referred-scene-referred.html#unbounded-sRGB-broken-model). Examples of affected editing operations are making a Levels gamma slider adjustment, dividing to flat-field an image, and using any layer Blend mode that involve multiply or divide.
A previously suggested way to fix problems created by a forced conversion to unbounded sRGB is to write new code that uses "BABL formats" to:
1. Use LCMS to retrieve the profile colorants of the RGB working space that the user would otherwise choose to use.
2. Create an new ICC profile RGB working space that uses:
a. The profile colorants of the RGB working space that the user would otherwise choose to use.
b. The sRGB TRC as the BABL-designated adequate substitute for "perceptually uniform" RGB.
3. Add new code to every editing operation that gives the wrong results in the unbounded sRGB color space. This added code will activate the following sequence of events:
a. Convert the affected image buffer(s) from unbounded sRGB to the new ICC profile RGB working space with the colorants of the RGB working space that the user would otherwise choose to use:
i. For some editing operations, the affected image buffer is just the one layer.
ii.For layer Blend mode operations, the entire layer stack that uses any layer Blend modes that give the wrong results in the unbounded sRGB color space (which in fact is most layer blend modes) would have to be converted to the new ICC profile RGB working space with the colorants of the RGB working space the user would otherwise choose to use.
b. Perform the affected editing operation. If the affected editing operation involves a layer Blend mode, the blended results would need to be made into a "New from Visible" layer. The convert/blend/"New from Visible" sequence would need to be repeated every time the user makes any modification to the affected layer stack.
c. Convert the image(s) from the new ICC profile with the colorants of the RGB working space that the user would otherwise choose to use, back to unbounded sRGB.
Problems with this previously suggested solution to problems created by a forced conversion to unbounded sRGB include:
1. This solution requires adding repetitive code to many editing operations. Developer time will be required not only to write the basic conversion code, but also to identify and modify all the requisite editing operations so the conversion code is activated as required.
2. For correct results, over 50% of the core editing operations that the GIMP UI makes available to the user will require converting image buffer(s) from unbounded sRGB to an LCMS-made ICC profile that uses the colorants of the RGB working space that the user would prefer to be using, and then back to unbounded sRGB.
3. This solution to the problems created by forced conversion of images to unbounded sRGB will require constantly converting image buffers back and forth between two RGB working spaces. This constant churning raises the possibility that many editing operations that are already somewhat slow, will be made even slower, chewing through CPU cycles to make the required color space conversions.
4. This solution puts the user's artistic intentions entirely at the mercy of developer decisions as to which RGB editing operations really do require a conversion to an RGB working space that uses the colorants of the user's chosen RGB working space.
Instead of keeping all of the hard-coded sRGB parameters, forcing a conversion to unbounded sRGB, and fixing the resulting problems, a better solution is as follows:
1. All hard-coded sRGB colorant-related and reference white parameters should be replaced with RGB working-space-specific parameters retrieved by LCMS from the user's chosen RGB working space.
2. The BABL code that switches between linear light and perceptually uniform RGB using the sRGB TRC (tone reproduction curve) should be kept.
3. To accomodate the BABL linear-to-perceptual sRGB-TRC-specific code, users must edit their images only in RGB working spaces that use the sRGB TRC. This can be accomplished in two ways:
i. Either inform the user that the user needs to convert their images to a version of their chosen RGB working space that already has the sRGB TRC, or else they will get wrong results. Appropriate ICC RGB working space profiles can be distributed with GIMP.
ii. Or else convert the image to a version of the user-chosen image profile that has the sRGB TRC:
a. Upon opening an image, and also when the user converts the image to a new RGB working space, use LCMS to make a new ICC profile that uses the user-chosen RGB working space's profile colorants and the sRGB TRC, and then convert the image to this new profile.
b. Retain the user-chosen image RGB working space information in case the user wants to convert the image back to the user-chosen RGB working space when exporting an image to a non-XCF file format.
This solution eliminates all the problems associated with a forced conversion to unbounded sRGB, and retains all the benefits of the currently coded BABL conversions between "linear light" and "perceptually uniform" RGB.
Below is a list of (hopefully all) the files that have hard-coded device and sRGB parameters, that need to be modified to use parameters pulled from the image RGB working space:
Files that use hard-coded sRGB unadapted Y values:
BABL
babl/extensions/ycbcr.c
GEGL
operations/common/svg-luminancetoalpha.c
operations/common/svg-saturate.c
operations/workshop/box-percentile.c
operations/workshop/disc-percentile.c
GIMP
libgimpcolor/gimprgb.h gives RGB_LUMINANCE_ #defines:
#define GIMP_RGB_LUMINANCE_RED (0.2126)
#define GIMP_RGB_LUMINANCE_GREEN (0.7152)
#define GIMP_RGB_LUMINANCE_BLUE (0.0722)
#define GIMP_RGB_LUMINANCE(r,g,b) ((r) * GIMP_RGB_LUMINANCE_RED + \
(g) * GIMP_RGB_LUMINANCE_GREEN + \
(b) * GIMP_RGB_LUMINANCE_BLUE)
libgimpcolor/gimprgb.c uses these #defines to write two more functions that calculate Luminance:
gimp_rgb_luminance
gimp_rgb_luminance_uchar
These files use #define GIMP_RGB_LUMINANCE(r,g,b) to calculate Luminance:
app/core/gimpimage-convert-type.c
app/gui/splash.c (splash.c is a UI that probably isn't and can't be color-managed by LCMS)
app/operations/gimplevelsconfig.c
app/operations/gimpoperationcolorize.c
app/operations/gimpoperationdesaturate.c
app/widgets/gimpgradienteditor.c
plug-ins/common/bump-map.c
plug-ins/common/colorify.c
plug-ins/common/displace.c
plug-ins/common/despeckle.c
plug-ins/common/engrave.c
plug-ins/common/file-aa.c
plug-ins/common/file-pnm.c
plug-ins/common/newsprint.c
plug-ins/common/oilify.c
plug-ins/file-fli/fli-gimp.c
plug-ins/fractal-explorer
plug-ins/gimpressionist/gimp.c
plug-ins/gradient-flare.c
plug-ins/pagecurl.c
plug-ins/pygimp/gimpcolormodule.c
This file uses gimp_rgb_luminance to calculate luminance:
plug-ins/pygimp/pygimp-colors.c
These files use gimp_rgb_luminance_uchar to calculate luminance:
libgimp/gimpdrawable.c
libgimp/gimppixelfetcher.c
plug-ins/common/file-mng.c
plug-ins/common/file-png.c
plug-ins/common/grid.c
plug-ins/gradient-flare.c
plug-ins/maze/maze-utils.c
Files that use hard-coded sRGB D50-adapted Y values
BABL
babl/base/rgb-constants.h (#defines for RGB_LUMINANCE_)
babl/base/model-gray.c (uses the RGB_LUMINANCE_ #defines)
extensions/grey.c (uses the RGB_LUMINANCE_ #defines)
GEGL
operations/workshop/snn-percentile.c
code in the opencl folder that repeats BABL code
GIMP code never uses D50-adapted sRGB Y values.
Fixing editing operations that currently use hard-coded sRGB Y values to calculate Luminance is straightfoward: Write a function that uses LCMS to retrieve the image's ICC profile's actual red, green, and blue colorant Y values and ferry the information to where it's needed. Modify the relevant files to use the RGB working space Y values instead of hard-coded Y values.
The BABL "extensions/CIE.c" file uses D65 sRGB color space xy values and the D65 sRGB reference white to convert to XYZ and then to LAB and LCH(ab). As currently programmed, the conversion to XYZ uses unadapted sRGB color space values, and so gives wrong results even for color managed sRGB images. The following files use the BABL conversion to XYZ and then to LAB and LCH(ab):
BABL
babl/tests/srgb_to_lab_u8.c
GEGL
gegl/operations/common/image-compare.c
gegl/operations/common/noise-cie-lch.c
GIMP
gimp/plug-ins/common/compose.c
gimp/plug-ins/common/decompose.c
gimp/app/operations/tests/test-operations.c
gimp/app/core/gimpimage-convert-type.c
To fix the code that converts from RGB to XYZ and then to LAB, write a function that uses LCMS to retrieve the image's ICC profile's actual red, green, and blue colorant X, Y, and Z values, plus the ICC profile's illuminant X, Y, and Z values (currently always D50), and ferry the information to where it's needed. The BABL file "extensions/CIE.c" should use the retrieved XYZ values to convert from RGB to XYZ. Once in the XYZ reference color space, the conversion to LAB should be done.
Code files in BABL/GEGL/GIMP that refer to YCbCr (not including jpeg/jp2-related and BABL format-defining code):
BABL
babl/base/model-ycbcr.c (NTSC)
extensions/ycbcr.c (BT.709)
tests/rgb_to_ycbcr.c (NTSC)
GEGL
opencl/colors.cl.h (NTSC?)
gegl/opencl/gegl-cl-color.c (NTSC?)
operations/common/cartoon.c (NTSC?)
GIMP
plug-ins/common/decompose.c (BT.709 and NTSC)
plug-ins/common/compose.c (BT.709 and NTSC)
The way to correct the YCbCr calculations to make them useable for all RGB working spaces is to use the generalized equations for converting from RGB to YCbCr, along with the LCMS-retrieved Y values for the image's RGB working space profile. The existing device-color-space-specific code gives the wrong results even for color-managed sRGB and NTSC images.
Other hard-coded NTSC parameters:
GEGL
opencl/colors.cl.h (used by operations/common/oilify.c) GEGL's "operations/common/oilify.c" should use Luminance calculations based on the Y values retrieved from the actual image ICC profile.
GIMP
libgimpcolor/gimprgb.h (in the deprecated GIMP_RGB_INTENSITY #defines, which don't seem to be used in any other GIMP code and so can be removed altogether)
libgimpcolor/gimprgb.c (in the deprecated functions gimp_rgb_intensity and gimp_rgb_intensity_uchar, which don't seem to be used in any other GIMP code and so can be removed altogether)
modules/gimpcolorwheel.c If the file "gimp/modules/gimpcolorwheel.c" is part of the color picker UI (or other UI that isn't color-managed), the code should use hard-coded sRGB values (not NTSC values) until such time as the color picker (or other) UI is color-managed.
plug-ins/common/hot.c GIMP's hot pixel repair code ("plug-ins/common/hot.c") has a precalculated NTSC-to-YIQ matrix. The current code gives wrong results even for sRGB images. It seems unlikely that YIQ is an especially felicitous RGB color space transform for identifying hot pixels in an ICC profile color managed image editing application.
NTSC broadcasting has ceased. So all NTSC-based code should be removed from BABL, GEGL, and GIMP.
The following BABL/GEGL/GIMP code files mention YUV:
BABL
extensions/gggl.c
GEGL
operations/external/ff-load.c
operations/external/v4l.c
operations/workshop/external/ff-save.c
GIMP
plug-ins/twain/twain.h
Probably none of the above-listed files except BABL's "extensions/gggl.c" file have anything to do with color-space-specific transforms. Whatever "extensions/gggl.c" does (possibly fast conversions between 8-bit integer and floating point for display on a BT.709 device?), there shouldn't be any device-color-space-specific transforms in an ICC profile color managed image editing application. In addition, there are some sRGB-specific tables in the BABL code, possibly also for fast conversions for 8-bit images. Not all 8-bit images are sRGB images. Not even all legacy XCF files produced using 8-bit GIMP are sRGB XCF files. I'm not sure how these tables are intended to be used with high bit depth GIMP (possibly for working with legacy 8-bit XCF files?). So I can't give advice on how to deal with them. I did compile a version of BABL with all such tables removed and never had a problem running GIMP. But I don't have any legacy 8-bit XCF files.
The BABL/GEGL/GIMP code base also contains files with hard-coded matrices, tables, and coefficients that are pre-calculated on the assumption that the image is in a specific color space. Such precalculated, hard-coded, color space-specific values need to be identified and dealt with on a case by case basis. Below are two examples of pre-baked, color-space-specific transforms:
1. GEGL uses hard-coded sRGB-based coefficients in the function "gfloat rgb_r55", in the file "operations/common/color-temperature.c" Functions in this file are called upon when you use GIMP's "Colors/Color Temperature" to raise or lower an image's color temperature. As currently coded, the color temperature changing code produces pleasing though colorimetrically inaccurate results for sRGB images. It produces very wrong results for non-sRGB images. One method for calculation color temperature changes, for which the required equations are readily available and easy to code, is to:
Convert the image from RGB to XYZ using the image RGB working space colorants retrieved by LCMS.
Perform a Bradford or CAT02 chromatic adaptation from TEMP1 to TEMP2.
Convert the image from XYZ to RGB.
2. The GIMP file "modules/display-filter-color-blind.c" simulates? enhances? what a colorblind person sees. This code uses RGB/LMS transforms that are hard-coded to use unadapted sRGB values, applicable to a "modern CRT", the likes of which haven't been in wide use for quite a few years now. This code is not valid for anyone using ICC profile color management, even for sRGB images. Nor is it valid for anyone viewing an sRGB image without color management, except on a monitor that has been calibrated to match sRGB. A way to generalize this code to work in a color-managed environment might be to:
Convert the image from the image's D50-adapted RGB working space to the user's monitor profile (which LCMS does anyway as the image is sent to the monitor)
Do the required RGB/XYZ/LMS transforms using the XYZ parameters retrieved from the monitor profile, with the sRGB profile as the usual "no monitor profile" fallback. XYZ/LMS equations can be found on Bruce Lindbloom's website. The alternative to generalizing the code to work with all monitor profiles in an ICC profile color-managed workflow is to include a UI notification that this display filter only produces valid results if:
Color management is disabled.
The image is an sRGB image.
The monitor is a CRT or other display device that's been calibrated to match sRGB, or else the user could try whatever sRGB simulation mode their LCD might provide.
Further examination of the code is likely to reveal a few other instances of hard-coded device-based and sRGB-specific matrices, tables, and coefficients. Such code has no place in an ICC profile color managed editing application.
Additional details on how to replace the hard-coded sRGB colorant-related and device-based parameters can be found here: http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html
**Patch 287578**, "Patch to retrieve the user-chosen RGB working space parameters.":
[0001-Retrieve-user-chosen-RGB-working-space-parameters.patch](/uploads/e94f541b8dad704ab2dbe569f72e332e/0001-Retrieve-user-chosen-RGB-working-space-parameters.patch)
Version: git masterhttps://gitlab.gnome.org/GNOME/gimp/-/issues/5037Any linear RGB using global variables with diff to master and patches2024-03-22T18:19:16ZElle StoneAny linear RGB using global variables with diff to master and patchesHere are diffs against master for my attempt at coding "Any linear RGB working space for GIMP-2.99 using two global variables to get and store the image's ICC profile:
Here's the diff for gimp:
[gimp-linear-anyrgb-diff-against-master.p...Here are diffs against master for my attempt at coding "Any linear RGB working space for GIMP-2.99 using two global variables to get and store the image's ICC profile:
Here's the diff for gimp:
[gimp-linear-anyrgb-diff-against-master.patch](/uploads/210a3063db83f161204b1939fb0aa83b/gimp-linear-anyrgb-diff-against-master.patch)
And for babl:
[babl-h-diff.patch](/uploads/a0a9625afe24399fa0c8227359e6b43f/babl-h-diff.patch)
These patches aren't intended as patch for default GIMP. But at least the code shows where the image's ICC profile color space information needs to go to color-manage the color-picking tools and some of GIMP's operations and blend modes.
Normally I do use GIMP's nice ability to switch between linear and perceptual encoding,. But the code I wrote for working in a linear well-behaved RGB working space doesn't allow for properly switching between linear and perceptual encoding. I think it could be extended to handle linear and perceptual encodings. But currently operations and filters that nominally should use perceptual encoding, only give correct results if the "gamma hack" is used, and similarly with blend modes such as screen, softlight, etc: choosing "linear blend" gives correct results, but the usually more useful "perceptual" blend does not.
Here is what works and doesn't work, with some work-arounds that show where the problem might be:
1. Levels and Curves, including Levels Pick White to color balance an image (https://gitlab.gnome.org/GNOME/gimp/-/issues/3015) IF "linear" encoding is used. Except oddly enough the histogram is switched - linear encoding shows a perceptual histogram and vice versa. This does not affect correct results, but it does mislead as to where points on a curve should go.
2. Dragging and dropping an RGB channel as a layer works (it doesn't work in default GIMP-2.99, but I haven't yet filed a bug report).
3. Picking colors, Sample Points, and using the sliders in the FG/BG tool to dial in colors produces correct linear results for the image's actual ICC profile linear RGB working space (https://gitlab.gnome.org/GNOME/gimp/-/issues/2050). The out-of-gamut indicators are not correct (https://gitlab.gnome.org/GNOME/gimp/-/issues/2022), probably because of the "perceptual re-encoding mentioned below. Also the LCh color squares to the left of the sliders have wrong shapes, possible from the perceptual encoding:
* None of this color-managed color picking/sampling goodness does any good, because painting/bucketfill/new layer from fg/bg color, etc all produce the wrong color, that color being the result of a perceptual re-encoding of the actual selected linearly-encoded color.
* In other words, somewhere - probably in GIMP? - there is a conversion to perceptual encoding between the picking and the painting of a color, that I haven't found.
* A work-around is to modify babl/babl/base/util.h so that the babl code that actually converts between perceptual and linear is disabled (just return "value" for all the TRC operations on that page). This also makes the "out of gamut" indicators work properly.
4. All the layer blend modes work, except as noted above regarding layer blend modes that nominally should work on perceptually encoded RGB.
5. All the RGB GEGL filters (tested: Exposure, Stretch Contrast, Monomixer, Gaussian blur, Extract RGB channels) on GIMP's menu (the ones that I checked) work, with the "only for linear encodings" caveat mentioned above. For example, High Pass, Value Propagate, and Edge Sobel (and probably the other Edge algorithms) need the gamma hack to produce "correct linear results" (no way to produce correct perceptual results).
6. The GEGL filters for LCh operations don't work (tested GEGL Saturation LCh and Hue-Chroma). The only way I could get these operations to produce correct results is either convert the image to linear sRGB from disk, or else replace the sRGB primaries in babl/babl-space.c code for making profiles with the primaries of the color space that the image is in. So change babl-space.c "sRGB" primaries to Rec.2020 primaries for working on a linear Rec.2020 image in GIMP.
Assuming it's possible to stop the perceptual re-encoding of picked colors (other than by disabling the perceptual/TRC functions in babl) and also possible to pass to various GEGL operations the actual image RGB working space, and assuming there is a way to tell various color-picking operations in GIMP what color space the image is actually in, without resorting to global variables, then here is a suggestion to make GIMP work in any well-behaved linear RGB working space:
* Change the function names of the current built-in sRGB profiles to something like "WorkingRGB..." - this effectively is what my patch does except I only make a linear profile.
* Make new functions for assigning linear or regular sRGB to images imported from disk that don't have embedded ICC profile/color space information. These would be similar to the current built-in Clay/AdobeRGB profile and only come into use during image import (and export/save, if the user doesn't assign or convert to some other RGB color space).
* Write code that allows GIMP to pass to GEGL the actual image RGB working space colorants.
Regarding passing the actual image RGB working space to GEGL, as far as I can tell:
* In "babl_format_with_space", when "space" is derived from the image's format, this "format" includes RGB encoding for "perceptual/linear", "floating point/integer", and "8-bit/16-bit/32-bit" - but doesn't include actual image RGB working space information.
* Similarly "const Babl *space = gegl_operation_get_source_space (operation, "input");" seems to always use sRGB rather than the image's actual RGB working space colorants.
My patches include some preliminary patches that have the function of making it easier for me to compare results with my GIMPCCE, and of having less code to deal with in various code files. Here's the individual patches in a zip file - the patch names give the reason for the patch:
[any-linear-RGB.tar.gz](/uploads/42d7eb636e1ff3b9733db49544cbd10d/any-linear-RGB.tar.gz)https://gitlab.gnome.org/GNOME/gimp/-/issues/540Enhance The Script-Fu Interface To Support Scrolling2024-03-22T14:17:08ZBugzillaEnhance The Script-Fu Interface To Support Scrolling## Submitted by GnuTux
**[Link to original bug (#725432)](https://bugzilla.gnome.org/show_bug.cgi?id=725432)**
## Description
Created attachment 270618
Patch To Add Support For Scrolling To: script-fu-interface.c
I would like to pr...## Submitted by GnuTux
**[Link to original bug (#725432)](https://bugzilla.gnome.org/show_bug.cgi?id=725432)**
## Description
Created attachment 270618
Patch To Add Support For Scrolling To: script-fu-interface.c
I would like to propose an Script-Fu Interface enhancement to enable support for scrolling. There are several reasons this would be a useful enhancement to GIMP.
As it now stands, if a script's dialog is too large to fit on the screen, it simply disappears off the edge. In Linux, users can alt-click and drag the dialog around to get to the needed input items, which is not really an optimal solution. Windows users are out of luck, as they have no way to get to the input fields that are off screen. In the case of Windows 7/8 users, there is no provision to gain access to these fields. A scrolling Script-Fu dialog resolves this problem. Even in Linux, scrolling a preferable option to alt-click and drag.
Another really good reason to implement this enhancement is to allow Script-Fu developers (like myself) the freedom to add all the needed input items to the dialog. For example, text effect & logo scripts can requires several input fields, just for the text, even before you begin processing the effects.
Personally, I have always felt limited by the constraints of the Script-Fu dialog, which is why I'm asking you to consider the small patch I'm attaching to this request. The patch adds scrolling to the Script-Fu dialog, with minimal changes to the interface code. The modification has been tested, works well and users really seem to like it.
Thank you for considering this enhancement request.
GnuTux
~~**Patch 270618**~~, "Patch To Add Support For Scrolling To: script-fu-interface.c":
[script-fu-interface.patch](/uploads/913eb11d7a828748333166034e357c53/script-fu-interface.patch)
Version: git masterhttps://gitlab.gnome.org/GNOME/gimp/-/issues/718Missing "Open With Gimp" in Right-Click Menu2024-03-20T11:40:37ZBugzillaMissing "Open With Gimp" in Right-Click Menu## Submitted by Dom
**[Link to original bug (#752759)](https://bugzilla.gnome.org/show_bug.cgi?id=752759)**
## Description
When I downloaded Gimp and installed it originally I always had the option to use Open With Gimp after a righ...## Submitted by Dom
**[Link to original bug (#752759)](https://bugzilla.gnome.org/show_bug.cgi?id=752759)**
## Description
When I downloaded Gimp and installed it originally I always had the option to use Open With Gimp after a right click. Now it seems to be missing. This tool was very important to me so I would like to know if this can be fixed, if it was in the update or what.
Version: 2.8.14
### See also
* [Bug 675971](https://bugzilla.gnome.org/show_bug.cgi?id=675971)
* [Bug 382683](https://bugzilla.gnome.org/show_bug.cgi?id=382683)
* [Bug 567998](https://bugzilla.gnome.org/show_bug.cgi?id=567998)2.10https://gitlab.gnome.org/GNOME/gimp/-/issues/1814The behavior of python registering is different in x64 (due to pygimp.interp)2024-03-20T10:42:37ZShiroYuki_MotThe behavior of python registering is different in x64 (due to pygimp.interp)GIMP version: GIMP 2.10.4
Operating System: Windows x64 Only
Package: Installer from gimp.org Over-Written Installed on 2.10.2 Both x86/x64
# Description of the bug
The behavior differs between x86 and x64, on Windows.<br />
The scri...GIMP version: GIMP 2.10.4
Operating System: Windows x64 Only
Package: Installer from gimp.org Over-Written Installed on 2.10.2 Both x86/x64
# Description of the bug
The behavior differs between x86 and x64, on Windows.<br />
The script registing to create a new 'Script-Py' item in the menu items (using <Toolbox>) is not working well on x64.<br />
Only Occurs x64 Win10. (x86 is correct, and the same script on 2.10.2 x64 was correct.)<br />
"c:\program files\gimp 2\bin\gimp-2.10" --verbose --console-messages<br />
Results Excerpt<br />
> *** Omission
> INIT: gimp_initialize<br />
> INIT: gimp_real_initialize<br />
> Parsing 'c:\program files\gimp 2\lib\gimp\2.0\interpreters\default.interp'<br />
> Parsing 'c:\program files\gimp 2\lib\gimp\2.0\interpreters\pygimp.interp'<br />
> GIMP-警告: インタープリターファイル 'c:\program files\gimp 2\lib\gimp\2.0\interpreters\pygimp.interp' 内で参照しているインタープリター 'python' は無効です。<br />
> (*GIMP - Warning: The interpreter 'python' referencing in the interpreter file 'c: \ program files \ gimp 2 \ lib \ gimp \ 2.0 \ interpreters \ pygimp.interp' is invalid.)<br />
> GIMP-警告: インタープリターファイル c:\program files\gimp 2\lib\gimp\2.0\interpreters\pygimp.interp に不適切な形式のバイナリ列があります。<br />
> (*GIMP - Warning: There is an incorrectly formatted binary string in the interpreter file c: \ program files \ gimp 2 \ lib \ gimp \ 2.0 \ interpreters \ pygimp.interp.)<br />
> Parsing 'c:\program files\gimp 2\lib\gimp\2.0\environ\default.env'<br />
> *** Omission<br />
> Parsing 'D:\Users\UserAAppData\Roaming\GIMP\2.10\pluginrc'<br />
> Querying plug-in: 'c:\program files\gimp 2\lib\gimp\2.0\plug-ins\file-rawtherapee.exe'<br />
> Querying plug-in: 'c:\program files\gimp 2\lib\gimp\2.0\plug-ins\file-darktable.exe'<br />
> Querying plug-in: 'D:\Users\UserA\AppData\Roaming\GIMP\2.10\plug-ins\Shiro_NEF_Loading.py'<br />
> GIMP-エラー: Unable to run plug-in "Shiro_NEF_Loading.py"<br />
> (D:\Users\UserA\AppData\Roaming\GIMP\2.10\plug-ins\Shiro_NEF_Loading.py)<br />
> 子プロセスを起動できませんでした (Exec format error)<br />
> (*Failed to start child process (Exec format error))<br />
> Initializing plug-in: 'c:\program files\gimp 2\lib\gimp\2.0\plug-ins\file-rawtherapee.exe'<br />
> Initializing plug-in: 'c:\program files\gimp 2\lib\gimp\2.0\plug-ins\file-darktable.exe'<br />
> Writing 'D:\Users\UserA\AppData\Roaming\GIMP\2.10\pluginrc'<br />
> Starting extension: 'extension-script-fu'<br />
> *** Omission<br />****
> Notice: (* [Transtated by Google])
Python Script (Menu)
> register(<br />
"python-fu-shiro-nef-loading", # func name<br />
"Load NEF File by Calling an external program", # description<br />
"Load NEF File by Calling an external program", # help<br />
"ShiroYuki_Mot", # author<br />
"Copyright 2018- ShiroYuki_Mot", # copyright notice<br />
"2018/05/01", # date created<br />
"<Toolbox>/Script-Py/写真加工/NEF Loading...", # menu path<br />
"", # image types on the script<br />
# params<br />
[ (PF_FILE, "original_file", ("Original NEF File (.NEF) : "), " <Select> "),
(PF_STRING, "fn_prefix_string", ("FileName Prefix String : "), 'c0m000f0_'),
(PF_DIRNAME, "temp_dir", ("Temporary Directory : "), " <Select> "),
(PF_FILENAME, "use_sidecar_file", ("* Use Existed SideCar File (.nksc) : "), " (Nothing) "),
(PF_OPTION,"command",("Program : "),0,listcommands())
],<br />
[], # results<br />
plugin_main # function<br />
)<br />
> main() <br />JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/3130Windows Installer, unattended unable to prevent file associations2024-03-20T01:28:09ZGhost UserWindows Installer, unattended unable to prevent file associationsGIMP version: 2.10.8
Operating System: Windows Server 2012 R2 / Windows 10
Package: https://download.gimp.org/mirror/pub/gimp/v2.10/windows/gimp-2.10.8-setup-2.exe
# Description of the bug
When silently installing gimp, we need the a...GIMP version: 2.10.8
Operating System: Windows Server 2012 R2 / Windows 10
Package: https://download.gimp.org/mirror/pub/gimp/v2.10/windows/gimp-2.10.8-setup-2.exe
# Description of the bug
When silently installing gimp, we need the ability to prevent it from associating itself over the top of (for example paint on Server 2012 R2) or the default image viewer on Windows 10. Basically the start-up time for gimp is so long that it drives people mad waiting for a jpeg to open with gimp if they just want to view it. Most applications support `/MERGETASKS !fileassoc` however I can't get any combination of flags to work on the command line.
I've had a look at https://github.com/GNOME/gimp/tree/master/build/windows/installer and I can't see any way to bypass it that can be injected from the command line, it looks like recompiling the installer with a different setup.ini (i.e. no file associations in there) is the only way to go at current.
# Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Install gimp using `/VERYSILENT /NORESTART "/MERGETASKS="!desktopicon,!fileassoc"`
2. Double click a jpeg!
…
Expected result:
Gimp doesn't associate itself to jpegs and leaves paint or the windows image viewer as the default
Actual result:
Gimp takes over all file associations
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/gimp/-/issues/2685Crash when distributing layers horizontally2024-03-12T16:36:34ZGhost UserCrash when distributing layers horizontallyGIMP version: 2.10.8
Operating System: Windows 10, 64 bits
Package: Installer from gimp.org
# Description of the bug
GIMP crashes when attempting to evenly distribute three layers. When trying to recover the file after restart, GIMP c...GIMP version: 2.10.8
Operating System: Windows 10, 64 bits
Package: Installer from gimp.org
# Description of the bug
GIMP crashes when attempting to evenly distribute three layers. When trying to recover the file after restart, GIMP crashes again.
# Reproduction
Always
Reproduction steps:
1. Choose alignment tool
2. Select three layers
3. Click on "distribute targets evenly in the the horizontal"
4. After the exception occurs, restart GIMP and choose to recover the file.
…
Expected result:
Arrange layers to be distributed evenly.
Actual result:
GIMP crashes.
# Additional information
Two reports attached - one for initial issue, second for failed recovery
```
Crash when distributing:
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=W:msys64-gtk2mingw64�ingcc.exe
COLLECT_LTO_WRAPPER=W:/msys64-gtk2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 8.2.0 (Rev3, Built by MSYS2 project)
using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.1 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.0 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.4 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: unhandled exception
Stack trace:
```
-------------------
Error occurred on Thursday, December 20, 2018 at 08:28:19.
gimp-2.10.exe caused an Access Violation at location 00007FF9B1124656 in module msvcrt.dll Writing to location 00000000016450A5.
AddrPC Params
00007FF9B1124656 0000000000EA0000 0000000000000002 0000000000000430 msvcrt.dll!memset
00000000618326BF 000000001C5699B0 0000000000000000 000000002A05C940 libgegl-0.4-0.dll!_gegl_buffer_get_unlocked [W:/msys64-gtk2/home/ender/gimp/gegl-0.4.12/gegl/buffer/gegl-buffer-access.c @ 2222]
00000000007854DC 0000000000ADD4D0 0000000067F0A82B 0000000000ADD4C0 gimp-2.10.exe!gimp_drawable_get_sub_preview_async_func [W:/msys64-gtk2/home/ender/gimp/gimp-2.10.8/app/core/gimpdrawable-preview.c @ 335]
0000000000732C51 0000000000000000 00000000045BE960 0000000000000000 gimp-2.10.exe! ?? [W:/msys64-gtk2/home/ender/gimp/gimp-2.10.8/app/core/gimp-parallel.cc @ 621]
0000000000732D60 00000000044BD730 0000000000000000 0000AB41558A3715 gimp-2.10.exe!gimp_parallel_run_async_thread_func [W:/msys64-gtk2/home/ender/gimp/gimp-2.10.8/app/core/gimp-parallel.cc @ 515]
0000000064A1CBB9 00000000045BE998 0000000000000000 0000000000000000 libglib-2.0-0.dll!g_test_get_filename
0000000064944B90 00000000045BE960 0000000000000000 0000000000000000 libwinpthread-1.dll!pthread_create_wrapper
00007FF9B10EAA96 00007FF9B11406D0 00000000044BE8C0 0000000000000000 msvcrt.dll!_callthreadstartex
00007FF9B10EAB6C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_threadstartex
00007FF9B12E3034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FF9B3803691 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart
gimp-2.10.exe 2.10.8.0
ntdll.dll 10.0.17134.471
KERNEL32.DLL 10.0.17134.1
KERNELBASE.dll 10.0.17134.441
msvcrt.dll 7.0.17134.1
SHELL32.dll 10.0.17134.441
cfgmgr32.dll 10.0.17134.1
libgimpcolor-2.0-0.dll
ucrtbase.dll 10.0.17134.319
shcore.dll 10.0.17134.112
RPCRT4.dll 10.0.17134.471
libgimpconfig-2.0-0.dll
combase.dll 10.0.17134.407
bcryptPrimitives.dll 10.0.17134.1
windows.storage.dll 10.0.17134.471
advapi32.dll 10.0.17134.471
sechost.dll 10.0.17134.319
libgimpmodule-2.0-0.dll
shlwapi.dll 10.0.17134.1
GDI32.dll 10.0.17134.285
libgimpthumb-2.0-0.dll
gdi32full.dll 10.0.17134.471
msvcp_win.dll 10.0.17134.137
USER32.dll 10.0.17134.376
win32u.dll 10.0.17134.1
kernel.appcore.dll 10.0.17134.112
profapi.dll 10.0.17134.1
powrprof.dll 10.0.17134.1
FLTLIB.DLL 10.0.17134.1
libgimpwidgets-2.0-0.dll
libgimpmath-2.0-0.dll
dbghelp.dll 6.3.9600.17298
libgimpbase-2.0-0.dll
ole32.dll 10.0.17134.407
libgdk_pixbuf-2.0-0.dll 2.38.0.0
libcairo-2.dll
libgio-2.0-0.dll 2.58.1.0
WS2_32.dll 10.0.17134.1
libglib-2.0-0.dll 2.58.1.0
libbabl-0.1-0.dll
libgegl-0.4-0.dll
libgobject-2.0-0.dll 2.58.1.0
libintl-8.dll 0.19.8.0
exchndl.dll 0.8.2.0
PSAPI.DLL 10.0.17134.1
liblcms2-2.dll
libgmodule-2.0-0.dll 2.58.1.0
libgexiv2-2.dll
libfreetype-6.dll 2.9.1.0
libfontconfig-1.dll
libgdk-win32-2.0-0.dll 2.24.32.0
IMM32.dll 10.0.17134.1
libpango-1.0-0.dll 1.42.4.0
libpangocairo-1.0-0.dll 1.42.4.0
libpangoft2-1.0-0.dll 1.42.4.0
libmypaint-1-3-0.dll
libharfbuzz-0.dll
libgegl-npd-0.4.dll
gdiplus.dll 10.0.17134.472
MSIMG32.dll 10.0.17134.1
zlib1.dll
libpixman-1-0.dll
DNSAPI.dll 10.0.17134.441
NSI.dll 10.0.17134.1
IPHLPAPI.DLL 10.0.17134.1
libffi-6.dll
libpng16-16.dll
libpcre-1.dll
libwinpthread-1.dll 1.0.0.0
libiconv-2.dll 1.15.0.0
VERSION.dll 10.0.17134.1
libbz2-1.dll
libexiv2.dll
libfribidi-0.dll
libexpat-1.dll
libthai-0.dll
DWrite.dll 10.0.17134.376
USP10.dll 10.0.17134.1
libjson-c-4.dll
libstdc++-6.dll
libgraphite2.dll
libdatrie-1.dll
libgcc_s_seh-1.dll
libgtk-win32-2.0-0.dll 2.24.32.0
mgwhelp.dll 0.8.2.0
libpangowin32-1.0-0.dll 1.42.4.0
comdlg32.dll 10.0.17134.1
COMCTL32.dll 5.82.17134.472
WINSPOOL.DRV 10.0.17134.319
PROPSYS.dll 7.0.17134.112
OLEAUT32.dll 10.0.17134.48
bcrypt.dll 10.0.17134.112
libatk-1.0-0.dll 2.30.0.0
uxtheme.dll 10.0.17134.1
clbcatq.dll 2001.12.10941.16384
MSCTF.dll 10.0.17134.376
cairo.dll
CIE.dll
double.dll
fast-float.dll
float.dll
gegl-fixups.dll
gggl-lies.dll
gggl-table-lies.dll
gggl-table.dll
gggl.dll
gimp-8bit.dll
grey.dll
half.dll
HCY.dll
HSL.dll
HSV.dll
naive-CMYK.dll
simple.dll
sse-half.dll
sse2-float.dll
sse2-int16.dll
sse2-int8.dll
sse4-int8.dll
two-table.dll
u16.dll
u32.dll
ycbcr.dll
gegl-core.dll
libjson-glib-1.0-0.dll
CRYPTSP.dll 10.0.17134.1
rsaenh.dll 10.0.17134.254
CRYPTBASE.dll 10.0.17134.1
winhttp.dll 10.0.17134.441
exr-load.dll
libIlmImf-2_2.dll
libHalf-2_2.dll
libIex-2_2.dll
libIlmThread-2_2.dll
libImath-2_2.dll
gegl-common-gpl3.dll
gegl-common.dll
gif-load.dll
jp2-load.dll
libjasper-4.dll
libjpeg-8.dll
jpg-load.dll
pixbuf.dll
png-load.dll
ppm-load.dll
raw-load.dll
libraw-16.dll
libgomp-1.dll
WSOCK32.dll 10.0.17134.1
rgbe-load.dll
svg-load.dll
librsvg-2-2.dll
libcroco-0.6-3.dll
libxml2-2.dll
liblzma-5.dll 5.2.4.0
text.dll
tiff-load.dll
libtiff-5.dll
webp-load.dll
libwebp-7.dll
exr-save.dll
jpg-save.dll
npy-save.dll
png-save.dll
ppm-save.dll
rgbe-save.dll
save-pixbuf.dll
sdl-display.dll
SDL.dll 1.2.14.0
WINMM.dll 10.0.17134.1
winmmbase.dll 10.0.17134.1
tiff-save.dll
webp-save.dll
lcms-from-profile.dll
npd.dll
path.dll
transformops.dll
vector-fill.dll
vector-stroke.dll
gegl-generated.dll
matting-levin.dll
libumfpack.dll
libcholmod.dll
libsuitesparseconfig.dll
libmetis.dll
libcamd.dll
libccolamd.dll
libcolamd.dll
libopenblas.dll
libamd.dll
libgfortran-5.dll
libquadmath-0.dll
seamless-clone.dll
libgegl-sc-0.4.dll
seamless-clone-compose.dll
libwimp.dll
comctl32.dll 6.10.17134.472
WindowsCodecs.dll 10.0.17134.345
libpixmap.dll
libpixbufloader-png.dll
dwmapi.dll 10.0.17134.1
libpixbufloader-svg.dll
mscms.dll 10.0.17134.1
USERENV.dll 10.0.17134.1
ColorAdapterClient.dll 10.0.17134.1
icm32.dll 10.0.17134.1
TextInputFramework.dll 10.0.17134.376
CoreUIComponents.dll 10.0.17134.376
CoreMessaging.dll 10.0.17134.471
ntmarta.dll 10.0.17134.1
wintypes.dll 10.0.17134.407
Oleacc.dll 7.2.17134.1
shfolder.dll 10.0.17134.1
apphelp.dll 10.0.17134.1
OneCoreUAPCommonProxyStub.dll 10.0.17134.1
MPR.dll 10.0.17134.1
drprov.dll 10.0.17134.1
WINSTA.dll 10.0.17134.1
ntlanman.dll 10.0.17134.1
davclnt.dll 10.0.17134.1
DAVHLPR.dll 10.0.17134.1
wkscli.dll 10.0.17134.1
cscapi.dll 10.0.17134.1
netutils.dll 10.0.17134.1
libpixbufloader-bmp.dll
WININET.dll 11.0.17134.441
iertutil.dll 11.0.17134.441
SspiCli.dll 10.0.17134.376
ondemandconnroutehelper.dll 10.0.17134.1
mswsock.dll 10.0.17134.1
WINNSI.DLL 10.0.17134.1
urlmon.dll 11.0.17134.407
rasadhlp.dll 10.0.17134.1
fwpuclnt.dll 10.0.17134.1
schannel.DLL 10.0.17134.376
CRYPT32.dll 10.0.17134.1
MSASN1.dll 10.0.17134.1
mskeyprotect.dll 10.0.17134.1
ncrypt.dll 10.0.17134.1
NTASN1.dll 10.0.17134.1
DPAPI.DLL 10.0.17134.1
WINTRUST.dll 10.0.17134.81
cryptnet.dll 10.0.17134.1
ncryptsslp.dll 10.0.17134.137
Windows 10.0.17134
DrMingw 0.8.2
```
Crash when attempting to recover:
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=W:msys64-gtk2mingw64�ingcc.exe
COLLECT_LTO_WRAPPER=W:/msys64-gtk2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 8.2.0 (Rev3, Built by MSYS2 project)
using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.1 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.0 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.4 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: unhandled exception
Stack trace:
```
-------------------
Error occurred on Thursday, December 20, 2018 at 08:41:57.
gimp-2.10.exe caused an Access Violation at location 00007FF9B1124656 in module msvcrt.dll Writing to location FFFFFFFFFC130C43.
AddrPC Params
00007FF9B1124656 00000000001F0000 0000000000000002 0000000000000590 msvcrt.dll!memset
0000000000D626BF 0000000018B04EF0 0000000000000000 0000000018D592E0 libgegl-0.4-0.dll!_gegl_buffer_get_unlocked [W:/msys64-gtk2/home/ender/gimp/gegl-0.4.12/gegl/buffer/gegl-buffer-access.c @ 2222]
00000000007854DC 0000000000ADD4D0 0000000067F0A7B2 0000000000ADD4C0 gimp-2.10.exe!gimp_drawable_get_sub_preview_async_func [W:/msys64-gtk2/home/ender/gimp/gimp-2.10.8/app/core/gimpdrawable-preview.c @ 335]
0000000000732C51 0000000000000000 00000000042BE1D0 0000000000000000 gimp-2.10.exe! ?? [W:/msys64-gtk2/home/ender/gimp/gimp-2.10.8/app/core/gimp-parallel.cc @ 621]
0000000000732D60 00000000042BE5F0 0000000000000000 0000F1E972BE8BF3 gimp-2.10.exe!gimp_parallel_run_async_thread_func [W:/msys64-gtk2/home/ender/gimp/gimp-2.10.8/app/core/gimp-parallel.cc @ 515]
0000000064A1CBB9 00000000042BE208 0000000000000000 0000000000000000 libglib-2.0-0.dll!g_test_get_filename
0000000064944B90 00000000042BE1D0 0000000000000000 0000000000000000 libwinpthread-1.dll!pthread_create_wrapper
00007FF9B10EAA96 00007FF9B11406D0 00000000042C0020 0000000000000000 msvcrt.dll!_callthreadstartex
00007FF9B10EAB6C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_threadstartex
00007FF9B12E3034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FF9B3803691 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart
gimp-2.10.exe 2.10.8.0
ntdll.dll 10.0.17134.471
KERNEL32.DLL 10.0.17134.1
KERNELBASE.dll 10.0.17134.441
msvcrt.dll 7.0.17134.1
SHELL32.dll 10.0.17134.441
cfgmgr32.dll 10.0.17134.1
ucrtbase.dll 10.0.17134.319
shcore.dll 10.0.17134.112
RPCRT4.dll 10.0.17134.471
combase.dll 10.0.17134.407
bcryptPrimitives.dll 10.0.17134.1
windows.storage.dll 10.0.17134.471
advapi32.dll 10.0.17134.471
sechost.dll 10.0.17134.319
shlwapi.dll 10.0.17134.1
GDI32.dll 10.0.17134.285
gdi32full.dll 10.0.17134.471
msvcp_win.dll 10.0.17134.137
USER32.dll 10.0.17134.376
win32u.dll 10.0.17134.1
kernel.appcore.dll 10.0.17134.112
profapi.dll 10.0.17134.1
powrprof.dll 10.0.17134.1
FLTLIB.DLL 10.0.17134.1
libgimpcolor-2.0-0.dll
libgimpconfig-2.0-0.dll
libgimpmath-2.0-0.dll
libgimpmodule-2.0-0.dll
libgimpthumb-2.0-0.dll
libgimpwidgets-2.0-0.dll
libgimpbase-2.0-0.dll
ole32.dll 10.0.17134.407
dbghelp.dll 6.3.9600.17298
libcairo-2.dll
libfontconfig-1.dll
libfreetype-6.dll 2.9.1.0
exchndl.dll 0.8.2.0
libgdk-win32-2.0-0.dll 2.24.32.0
PSAPI.DLL 10.0.17134.1
IMM32.dll 10.0.17134.1
libgexiv2-2.dll
libgdk_pixbuf-2.0-0.dll 2.38.0.0
libgio-2.0-0.dll 2.58.1.0
WS2_32.dll 10.0.17134.1
libglib-2.0-0.dll 2.58.1.0
libgobject-2.0-0.dll 2.58.1.0
libgtk-win32-2.0-0.dll 2.24.32.0
libharfbuzz-0.dll
comdlg32.dll 10.0.17134.1
libintl-8.dll 0.19.8.0
libmypaint-1-3-0.dll
liblcms2-2.dll
libpango-1.0-0.dll 1.42.4.0
libpangocairo-1.0-0.dll 1.42.4.0
libpangoft2-1.0-0.dll 1.42.4.0
zlib1.dll
libbabl-0.1-0.dll
libgegl-npd-0.4.dll
libgmodule-2.0-0.dll 2.58.1.0
MSIMG32.dll 10.0.17134.1
libpixman-1-0.dll
libpng16-16.dll
libexpat-1.dll
libiconv-2.dll 1.15.0.0
libbz2-1.dll
VERSION.dll 10.0.17134.1
libstdc++-6.dll
libexiv2.dll
IPHLPAPI.DLL 10.0.17134.1
DNSAPI.dll 10.0.17134.441
NSI.dll 10.0.17134.1
gdiplus.dll 10.0.17134.472
libwinpthread-1.dll 1.0.0.0
libpcre-1.dll
libffi-6.dll
DWrite.dll 10.0.17134.376
USP10.dll 10.0.17134.1
COMCTL32.dll 5.82.17134.472
libgraphite2.dll
libatk-1.0-0.dll 2.30.0.0
WINSPOOL.DRV 10.0.17134.319
libjson-c-4.dll
libfribidi-0.dll
libthai-0.dll
PROPSYS.dll 7.0.17134.112
bcrypt.dll 10.0.17134.112
OLEAUT32.dll 10.0.17134.48
libdatrie-1.dll
libgegl-0.4-0.dll
libgcc_s_seh-1.dll
mgwhelp.dll 0.8.2.0
libpangowin32-1.0-0.dll 1.42.4.0
uxtheme.dll 10.0.17134.1
clbcatq.dll 2001.12.10941.16384
MSCTF.dll 10.0.17134.376
cairo.dll
CIE.dll
double.dll
fast-float.dll
float.dll
gegl-fixups.dll
gggl-lies.dll
gggl-table-lies.dll
gggl-table.dll
gggl.dll
gimp-8bit.dll
grey.dll
half.dll
HCY.dll
HSL.dll
HSV.dll
naive-CMYK.dll
simple.dll
sse-half.dll
sse2-float.dll
sse2-int16.dll
sse2-int8.dll
sse4-int8.dll
two-table.dll
u16.dll
u32.dll
ycbcr.dll
gegl-core.dll
libjson-glib-1.0-0.dll
CRYPTSP.dll 10.0.17134.1
rsaenh.dll 10.0.17134.254
CRYPTBASE.dll 10.0.17134.1
winhttp.dll 10.0.17134.441
exr-load.dll
libIlmImf-2_2.dll
libHalf-2_2.dll
libIex-2_2.dll
libIlmThread-2_2.dll
libImath-2_2.dll
gegl-common-gpl3.dll
gegl-common.dll
gif-load.dll
jp2-load.dll
libjasper-4.dll
libjpeg-8.dll
jpg-load.dll
pixbuf.dll
png-load.dll
ppm-load.dll
raw-load.dll
libraw-16.dll
libgomp-1.dll
WSOCK32.dll 10.0.17134.1
rgbe-load.dll
svg-load.dll
librsvg-2-2.dll
libcroco-0.6-3.dll
libxml2-2.dll
liblzma-5.dll 5.2.4.0
text.dll
tiff-load.dll
libtiff-5.dll
webp-load.dll
libwebp-7.dll
exr-save.dll
jpg-save.dll
npy-save.dll
png-save.dll
ppm-save.dll
rgbe-save.dll
save-pixbuf.dll
sdl-display.dll
SDL.dll 1.2.14.0
WINMM.dll 10.0.17134.1
WINMMBASE.dll 10.0.17134.1
tiff-save.dll
webp-save.dll
lcms-from-profile.dll
npd.dll
path.dll
transformops.dll
vector-fill.dll
vector-stroke.dll
gegl-generated.dll
matting-levin.dll
libumfpack.dll
libcholmod.dll
libsuitesparseconfig.dll
libmetis.dll
libcamd.dll
libccolamd.dll
libcolamd.dll
libopenblas.dll
libamd.dll
libgfortran-5.dll
libquadmath-0.dll
seamless-clone.dll
libgegl-sc-0.4.dll
seamless-clone-compose.dll
libwimp.dll
comctl32.dll 6.10.17134.472
WindowsCodecs.dll 10.0.17134.345
libpixmap.dll
libpixbufloader-png.dll
dwmapi.dll 10.0.17134.1
libpixbufloader-svg.dll
mscms.dll 10.0.17134.1
USERENV.dll 10.0.17134.1
ColorAdapterClient.dll 10.0.17134.1
icm32.dll 10.0.17134.1
TextInputFramework.dll 10.0.17134.376
CoreUIComponents.dll 10.0.17134.376
CoreMessaging.dll 10.0.17134.471
ntmarta.dll 10.0.17134.1
wintypes.dll 10.0.17134.407
Oleacc.dll 7.2.17134.1
shfolder.dll 10.0.17134.1
apphelp.dll 10.0.17134.1
Windows 10.0.17134
DrMingw 0.8.2
```2.10https://gitlab.gnome.org/GNOME/gimp/-/issues/4235Gimp crash after resize and reposition a text field2024-03-12T16:31:52ZChristian DieterichGimp crash after resize and reposition a text fieldGIMP version: 2.10.14
Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).
Operating System: Windows 10
Package: direc...GIMP version: 2.10.14
Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).
Operating System: Windows 10
Package: direct from gimp.org
# Description of the bug
I wanted to change the color profil. so i reinstalled 2.8 because there it is a plug in.
But as i cant open my 2.10 files in 2.8 I reinstalled 2.10 again.
Since then always when i want to resize or change the position of the textfiled (which starts with "Wer:")
Gimp will crash
# Reproduction
Is the bug reproducible? [Always / Randomly / Happened only once ]
Reproduction steps:
1. Changed the Size/Position of a Text field of a already created (Attached file Text "Wer: ..."
[Plakat_A3_Druck.xcf](/uploads/10df39edd66cfc0f2987ad7cbcf24463/Plakat_A3_Druck.xcf)
…
Expected result:
Actual result:
# Additional information
If you have a backtrace for a crash or a warning, paste it here.
```
GNU Image Manipulation Program version 2.10.14
git-describe: GIMP_2_10_12-511-ga4f55d6c7e
C compiler:
Using built-in specs.
COLLECT_GCC=W:msys64-gtk2mingw64�ingcc.exe
COLLECT_LTO_WRAPPER=W:/msys64-gtk2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-9.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --enable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 9.2.0 (Rev2, Built by MSYS2 project)
using babl version 0.1.72 (compiled against version 0.1.72)
using GEGL version 0.4.18 (compiled against version 0.4.18)
using GLib version 2.62.1 (compiled against version 2.62.1)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.43.0 (compiled against version 1.43.0)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)
```
> fatal error: unhandled exception
Stack trace:
```
-------------------
Error occurred on Wednesday, November 13, 2019 at 23:20:29.
gimp-2.10.exe caused an Access Violation at location 000000007002DFE0 in module libgegl-0.4-0.dll Writing to location 0000000120F39000.
AddrPC Params
000000007002DFE0 0000000000000001 00007FF811ABE59B 000000000000000B libgegl-0.4-0.dll!gegl_compression_nop_init
000000007002E0AB 000000000000000B 0000000018FCCD60 0000000000000004 libgegl-0.4-0.dll!gegl_compression_nop_init
000000007003E299 0000000000000400 0000000000000400 0000000060263CC0 libgegl-0.4-0.dll!gegl_tile_backend_swap_get_type
000000007004043D 0000000000000200 0000000000000000 000000001924C210 libgegl-0.4-0.dll!gegl_tile_handler_cache_insert
00000000700414D3 00000000188E9C40 00000000700414D3 0000000060263CC0 libgegl-0.4-0.dll!gegl_tile_handler_log_get_type
0000000070040D9C 0000000000000200 00000000641CC1C2 0000000000000200 libgegl-0.4-0.dll!gegl_tile_handler_empty_new_tile
0000000070029E93 0000000000000000 0000000003D5CA40 0000000003D5CA40 libgegl-0.4-0.dll!gegl_buffer_swap_has_file
0000000070029E93 0000000000000020 0000008600000086 00000000188E9C40 libgegl-0.4-0.dll!gegl_buffer_swap_has_file
000000007001EA6C 0000008000000020 0000000003D5CA40 000000005FA206F0 libgegl-0.4-0.dll!gegl_resample_bilinear
000000007001FCBF 0000000060017320 000000005FF7B270 0000000000000000 libgegl-0.4-0.dll!gegl_resample_bilinear
0000000070020060 0000000015A59800 000000007003FC77 000000005FE4ABA0 libgegl-0.4-0.dll!gegl_resample_bilinear
0000000070021A40 0000000060017320 0000000000000260 0000000000000000 libgegl-0.4-0.dll!gegl_resample_bilinear
0000000070025989 0000000015A59800 0000000003D23310 000000007009B140 libgegl-0.4-0.dll!gegl_buffer_iterator_next
0000000070056B67 0000000000000000 0000000064A49379 00000000017F2690 libgegl-0.4-0.dll!gegl_operation_point_composer_get_type
000000007000666F 0000000000000000 00000000017F2730 0000000000000000 libgegl-0.4-0.dll!gegl_matrix3_to_string
0000000070006573 0000000000000000 0000000000000000 00003D4AACAAA730 libgegl-0.4-0.dll!gegl_matrix3_to_string
0000000064A21EE1 0000000003CE7250 0000000000000000 0000000000000000 libglib-2.0-0.dll!g_test_get_filename
0000000064945092 0000000003D1E3F0 0000000000000000 0000000003CE7250 libwinpthread-1.dll!pthread_create_wrapper
00007FF811ADB04A 00007FF811B306D0 0000000003CE7250 0000000000000000 msvcrt.dll!_callthreadstartex
00007FF811ADB11C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_threadstartex
00007FF810DD7BD4 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FF811BECED1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart
gimp-2.10.exe 2.10.14.0
ntdll.dll 10.0.18362.418
KERNEL32.DLL 10.0.18362.329
KERNELBASE.dll 10.0.18362.476
msvcrt.dll 7.0.18362.1
ole32.dll 10.0.18362.113
combase.dll 10.0.18362.449
ucrtbase.dll 10.0.18362.387
RPCRT4.dll 10.0.18362.476
bcryptPrimitives.dll 10.0.18362.295
libgimpcolor-2.0-0.dll
advapi32.dll 10.0.18362.329
sechost.dll 10.0.18362.267
libgimpconfig-2.0-0.dll
GDI32.dll 10.0.18362.1
win32u.dll 10.0.18362.476
libgimpmath-2.0-0.dll
gdi32full.dll 10.0.18362.476
msvcp_win.dll 10.0.18362.387
libgimpmodule-2.0-0.dll
USER32.dll 10.0.18362.476
libgimpthumb-2.0-0.dll
SHELL32.dll 10.0.18362.449
cfgmgr32.dll 10.0.18362.387
libgimpwidgets-2.0-0.dll
shcore.dll 10.0.18362.1
libgimpbase-2.0-0.dll
windows.storage.dll 10.0.18362.449
profapi.dll 10.0.18362.1
powrprof.dll 10.0.18362.1
dbghelp.dll 6.3.9600.17298
UMPDC.dll
shlwapi.dll 10.0.18362.1
kernel.appcore.dll 10.0.18362.1
cryptsp.dll 10.0.18362.1
libcairo-2.dll
libbabl-0.1-0.dll
libgdk_pixbuf-2.0-0.dll 2.40.0.0
libgegl-0.4-0.dll
libgio-2.0-0.dll 2.62.1.0
WS2_32.dll 10.0.18362.387
libglib-2.0-0.dll 2.62.1.0
libgobject-2.0-0.dll 2.62.1.0
liblcms2-2.dll
libintl-8.dll 0.19.8.0
libgmodule-2.0-0.dll 2.62.1.0
libgdk-win32-2.0-0.dll 2.24.32.0
libgtk-win32-2.0-0.dll 2.24.32.0
IMM32.dll 10.0.18362.387
libpango-1.0-0.dll 1.43.0.0
libpangocairo-1.0-0.dll 1.43.0.0
comdlg32.dll 10.0.18362.418
libgexiv2-2.dll
exchndl.dll 0.8.2.0
PSAPI.DLL 10.0.18362.1
libfontconfig-1.dll
libfreetype-6.dll 2.10.1.0
libgegl-npd-0.4.dll
libharfbuzz-0.dll
libmypaint-1-3-0.dll
zlib1.dll
libpangoft2-1.0-0.dll 1.43.0.0
MSIMG32.dll 10.0.18362.175
libpixman-1-0.dll
libpng16-16.dll
gdiplus.dll 10.0.18362.476
IPHLPAPI.DLL 10.0.18362.1
libwinpthread-1.dll 1.0.0.0
libffi-6.dll
DNSAPI.dll 10.0.18362.267
NSI.dll 10.0.18362.449
libpcre-1.dll
libiconv-2.dll 1.16.0.0
libfribidi-0.dll
libthai-0.dll
libpangowin32-1.0-0.dll 1.43.0.0
COMCTL32.dll 5.82.18362.476
libstdc++-6.dll
libexiv2.dll
libatk-1.0-0.dll 2.34.1.0
WINSPOOL.DRV 10.0.18362.267
bcrypt.dll 10.0.18362.267
VERSION.dll 10.0.18362.1
libexpat-1.dll
libbz2-1.dll
libgraphite2.dll
libjson-c-4.dll
USP10.dll 10.0.18362.476
libdatrie-1.dll
PROPSYS.dll 7.0.18362.267
OLEAUT32.dll 10.0.18362.329
libgcc_s_seh-1.dll
mgwhelp.dll 0.8.2.0
uxtheme.dll 10.0.18362.449
clbcatq.dll 2001.12.10941.16384
MSCTF.dll 10.0.18362.387
avx2-int8.dll
cairo.dll
CIE.dll
double.dll
fast-float.dll
float.dll
gegl-fixups.dll
gggl-lies.dll
gggl-table-lies.dll
gggl-table.dll
gggl.dll
gimp-8bit.dll
grey.dll
half.dll
HCY.dll
HSL.dll
HSV.dll
naive-CMYK.dll
simple.dll
sse-half.dll
sse2-float.dll
sse2-int16.dll
sse2-int8.dll
sse4-int8.dll
two-table.dll
u16.dll
u32.dll
ycbcr.dll
gegl-core.dll
libjson-glib-1.0-0.dll
rsaenh.dll 10.0.18362.1
CRYPTBASE.dll 10.0.18362.1
winhttp.dll 10.0.18362.449
exr-load.dll
libIlmImf-2_3.dll
libIex-2_3.dll
libHalf-2_3.dll
libIlmThread-2_3.dll
libImath-2_3.dll
gegl-common-gpl3.dll
gegl-common.dll
gif-load.dll
jp2-load.dll
libjasper-4.dll
libjpeg-8.dll
jpg-load.dll
pixbuf-load.dll
png-load.dll
ppm-load.dll
raw-load.dll
libraw-19.dll
WSOCK32.dll 10.0.18362.1
rgbe-load.dll
svg-load.dll
librsvg-2-2.dll
libcroco-0.6-3.dll
libxml2-2.dll
liblzma-5.dll 5.2.4.0
text.dll
tiff-load.dll
libtiff-5.dll
libzstd.dll
webp-load.dll
libwebp-7.dll
exr-save.dll
jpg-save.dll
npy-save.dll
pixbuf-save.dll
png-save.dll
ppm-save.dll
rgbe-save.dll
sdl2-display.dll
SDL2.dll 2.0.10.0
SETUPAPI.dll 10.0.18362.1
WINMM.dll 10.0.18362.1
winmmbase.dll 10.0.18362.1
tiff-save.dll
webp-save.dll
gegl-common-cxx.dll
lcms-from-profile.dll
npd.dll
path.dll
transformops.dll
vector-fill.dll
vector-stroke.dll
gegl-generated.dll
matting-levin.dll
libumfpack.dll
libamd.dll
libsuitesparseconfig.dll
libopenblas.dll
libcholmod.dll
libgfortran-5.dll
libmetis.dll
libgomp-1.dll
libcamd.dll
libccolamd.dll
libcolamd.dll
libquadmath-0.dll
seamless-clone.dll
libgegl-sc-0.4.dll
seamless-clone-compose.dll
libwimp.dll
libpixbufloader-png.dll
mscms.dll 10.0.18362.267
USERENV.dll 10.0.18362.387
ColorAdapterClient.dll 10.0.18362.267
icm32.dll 10.0.18362.267
TextInputFramework.dll 10.0.18362.267
CoreUIComponents.dll 10.0.18362.207
CoreMessaging.dll 10.0.18362.1
ntmarta.dll 10.0.18362.1
wintypes.dll 10.0.18362.449
iertutil.dll 11.0.18362.449
shfolder.dll 10.0.18362.1
apphelp.dll 10.0.18362.1
libpixbufloader-svg.dll
comctl32.dll 6.10.18362.476
WindowsCodecs.dll 10.0.18362.1
Windows 10.0.18362
DrMingw 0.8.2
```https://gitlab.gnome.org/GNOME/gimp/-/issues/5342Export to 16-bit PNG incorrectly sets background color to 8-bit2024-03-11T17:33:17ZRupert WeberExport to 16-bit PNG incorrectly sets background color to 8-bitGIMP version:2.99.1
When exporting to PNG files, (if "Save background color" is ticked) the background color is always set to 8-bit, even for 16-bit PNG files.
But the color specified in png_set_bKGD() has to match the export bit-depth....GIMP version:2.99.1
When exporting to PNG files, (if "Save background color" is ticked) the background color is always set to 8-bit, even for 16-bit PNG files.
But the color specified in png_set_bKGD() has to match the export bit-depth.
(See [PNG file specification](http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html), about 3/4 page down.)
I ran into this while using GIMP-created PNGs to test some PNG-reading code I wrote. Drove me nuts. ;o)
# Reproduction
Is the bug reproducible? [Always]
Reproduction steps:
1. Export a 16-bit PNG with saved background color
2. Run "pngcheck -v my16bitimage.png | grep -v IDAT"
3. Look for "chunk bKGD at offset ..."
Expected result: 16-bit color spec
Actual result: 8-bit color spec
I am attaching a patch with a proposed fix.
Regards
Rupert
[0001-On-export-to-16-bit-PNG-the-background-color-bKGD-ne.patch](/uploads/68f44034a814661adad61f49216b315c/0001-On-export-to-16-bit-PNG-the-background-color-bKGD-ne.patch)3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/5363Incorrect gamma on PNG export2024-03-11T14:28:20ZRupert WeberIncorrect gamma on PNG exportGIMP version: 2.99
Operating System: [all]
Gimp will write wrong gamma information (gAMA chunk) to PNG files for non-sRGB (actually non-2.2-gamma) images.
Code inspection shows that on PNG export Gimp will either write the gamma value...GIMP version: 2.99
Operating System: [all]
Gimp will write wrong gamma information (gAMA chunk) to PNG files for non-sRGB (actually non-2.2-gamma) images.
Code inspection shows that on PNG export Gimp will either write the gamma value found in a "gamma"-parasite or the hard-coded value 2.2 if there is no such parasite.
If I understand correctly, that parasite can only come from a PNG-import and does not necessarily match the actual gamma of the image to be exported?
# Reproduction
Is the bug reproducible? [Always]
Reproduction steps:
1. Open or create any 16-bit linear image
2. Export as 16-bit PNG, check option to write gamma.
…
Expected result: gAMA chunk in PNG set to gamma value matching the image data
Actual result: PNG set to gamma 0.45455 ( = 1 / 2.2)
# Additional information
I'd love to help with a patch, but I have no idea how to retrieve the actual gamma value from the image.
Regards
Rupert2.99.6https://gitlab.gnome.org/GNOME/gimp/-/issues/130Use PangoFontDescriptions internally for GimpText, instead of serialized strings2024-03-10T21:31:43ZBugzillaUse PangoFontDescriptions internally for GimpText, instead of serialized strings## Submitted by Manish Singh
**[Link to original bug (#168102)](https://bugzilla.gnome.org/show_bug.cgi?id=168102)**
## Description
We're doing some contortions to workaround bug #166540, and if bug #168085 is
fixed, some of our fon...## Submitted by Manish Singh
**[Link to original bug (#168102)](https://bugzilla.gnome.org/show_bug.cgi?id=168102)**
## Description
We're doing some contortions to workaround bug #166540, and if bug #168085 is
fixed, some of our font names can potentionally look even uglier.
If we work on PangoFontDescriptions internally, resolving GIMP fonts to pango
fonts is nicely disambiguated. It also gives us the opportunity to pretty print
the names.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/gimp/-/issues/435Text tool: some font names end with additional comma2024-03-09T19:39:11ZBugzillaText tool: some font names end with additional comma## Submitted by Gerald Giese
**[Link to original bug (#687505)](https://bugzilla.gnome.org/show_bug.cgi?id=687505)**
## Description
Created attachment 227964
Font name comma bug, gimp 2.8.2 and Word 2007
Some font names ending with...## Submitted by Gerald Giese
**[Link to original bug (#687505)](https://bugzilla.gnome.org/show_bug.cgi?id=687505)**
## Description
Created attachment 227964
Font name comma bug, gimp 2.8.2 and Word 2007
Some font names ending with an additional comma.
In all other applications the font name is correct (no comma).
If i open a 2.6-xcf with textfield, and i edit the text, gimp doesn't connect to the correct font, because font name has no comma at the end but gimp says there is only a font with comma at the end on my system.
See attached image with Gimp 2.8.2 and Word 2007. Gimp has additional comma.
Fonts effected:
Arial Rounded MT Bold
Bauhaus 93,
Bookshelf Symbol 7
Britannic Bold
Cooper Black
Copperplate Gothic Bold
Copperplate Gothic Light
Gill Sans Ultra Bold
Informal Roman
Modern No. 20
Rage italic,
Times New Roman
Webdings 2
Webdings 3
Windows XP SP3, german
**Attachment 227964**, "Font name comma bug, gimp 2.8.2 and Word 2007":
![gimp_font_name_bug](/uploads/c3c223244f48d600c7baba4a7f743f1d/gimp_font_name_bug.jpg)
Version: 2.8.2https://gitlab.gnome.org/GNOME/gimp/-/issues/11009Add "StartupWMClass" desktop file property to 2.10.x (cherry-pick from 2-99 b...2024-03-06T16:14:03ZYevhen PopokAdd "StartupWMClass" desktop file property to 2.10.x (cherry-pick from 2-99 branch)<!-- ⚠️ IMPORTANT: READ ME! ⚠️
This is the default template for bug reports.
For feature requests or performance issues, please switch instead to the appropriate template in the "Choose a template" list.
It is important that you fill al...<!-- ⚠️ IMPORTANT: READ ME! ⚠️
This is the default template for bug reports.
For feature requests or performance issues, please switch instead to the appropriate template in the "Choose a template" list.
It is important that you fill all the fields of the template.
-->
### Environment/Versions
- GIMP version: 2.10.36
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Flatpak
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
GIMP 2.10.x desktop file doesn't have "StartupWMClass" property. That makes impossible to "Pin"/"Add to favorites" running GIMP instance on taskbar/panel on desktop environments like KDE Plasma. This issue is already fixed in dev branches ([Commit 1c2d1003](https://gitlab.gnome.org/GNOME/gimp/-/commit/1c2d1003e55fce527c3dd3634fd784214178797c)). I believe it makes sense to cherry-pick this change to 2.10.38
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. On KDE Plasma install and laaunch GNU Image Manipulation Program v2.10
2. Right click on the running GIMP taskbar item on the panel
…
Expected result:
There is the "Pin to Task Manager" option
Actual result:
"Pin to Task Manager" option is not available
### Additional information
I can fix it by creating desktop file override (e.g., `$HOME/.local/share/applications/org.gimp.GIMP.desktop`) and adding there line `StartupWMClass=gimp-2.10`
---
Downstream Flatpak issue: https://github.com/flathub/org.gimp.GIMP/issues/1622.10.38https://gitlab.gnome.org/GNOME/gimp/-/issues/7669Help menu needs some TLC2024-03-05T11:18:43ZSilverWoodchuck47Help menu needs some TLCGIMP 2.10.30 Win7-32
### Description of the feature
Reorder the commands in the Help menu:
![HelpMenu](/uploads/c7193bfdb0bc36c40aeeca51f8fa1d06/HelpMenu.png)
1. PLEASE put **About GIMP** at the bottom, as it appears in so much other...GIMP 2.10.30 Win7-32
### Description of the feature
Reorder the commands in the Help menu:
![HelpMenu](/uploads/c7193bfdb0bc36c40aeeca51f8fa1d06/HelpMenu.png)
1. PLEASE put **About GIMP** at the bottom, as it appears in so much other software.
2. Move the other commands so they are grouped by similar functionality:
Help
Context Help
User Manual
Tip of the Day
GIMP Online
_
Search and Run Command
_
Plug-in Browser
Procedure Browser
_
Bug Report and Feature Requests
About GIMP2.99.18Alexandre ProkoudineAlexandre Prokoudinehttps://gitlab.gnome.org/GNOME/gimp/-/issues/573blend tool: the description and the order of repeat mode: Truncate (GIMP_REPE...2024-03-01T00:56:04ZBugzillablend tool: the description and the order of repeat mode: Truncate (GIMP_REPEAT_TRUNCATE)## Submitted by Kiyotaka NISHIBORI
**[Link to original bug (#734933)](https://bugzilla.gnome.org/show_bug.cgi?id=734933)**
## Description
Created attachment 283637
painting with blend tool with each repeat mode
Step for reproductio...## Submitted by Kiyotaka NISHIBORI
**[Link to original bug (#734933)](https://bugzilla.gnome.org/show_bug.cgi?id=734933)**
## Description
Created attachment 283637
painting with blend tool with each repeat mode
Step for reproduction:
1. Open GIMP and select blend tool.
2. pull down repaet-mode combobox at tool option dialog.
Actual result:
the description of each modes and the order in the list are:
1st. row: 'None (extend)'
2nd. row: 'Sawtooth Wave'
3rd. row: 'Triangular Wave'
*4th. row: *'Truncate'
Expected result:
1st. row: 'None (extend)'
*2nd. row: *'None (truncate)'
3rd. row: 'Sawtooth Wave'
4th. row: 'Triangular Wave'
Other information:
See attached image. This is result by using blend tool with each repeat mode.
It shows that a gradient is *not repeated* when 'Truncate' mode is used. this means that 'Truncate' mode is a variety of 'None' mode.
So, from the view of usability, I think that the mode should be named 'None (truncate)' instead of 'Truncate' and that the mode should be placed near 'None (extend)' mode in the list.
**Attachment 283637**, "painting with blend tool with each repeat mode":
![blend-repeat_mode](/uploads/5a090035a3b378989e2c55c939d9c671/blend-repeat_mode.png)
Version: git master3.0 RC1