GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-23T21:12:12Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/3480Save dialog for a decomposed layer stack suggested .tif instead of .xcf2024-03-23T21:12:12ZElle StoneSave dialog for a decomposed layer stack suggested .tif instead of .xcfWhen opening a tiff from disk, and then immediately selecting to "save" or "save as", the "save" dialog suggests the base tiff file name, with the extension ".xcf". By now, I'm guessing everyone has gotten use to this behavior (even if s...When opening a tiff from disk, and then immediately selecting to "save" or "save as", the "save" dialog suggests the base tiff file name, with the extension ".xcf". By now, I'm guessing everyone has gotten use to this behavior (even if some people still think it's unfriendly behavior :) ).
However, after decomposing the newly-opened (and not yet saved as .xcf) tiff to RGB or LCH (my sample tiff only had one layer), and then selecting to "save" or "save as" the decomposed layer stack, the "save" and "save as" dialogs both offered to save the layer stack as a tiff, which surprised me. Yes, tiffs support multiple layers, but that's not the point.
When electing to use the GIMP-suggested "tif" file extension for saving the decomposed layer stack, a dialog popped up saying (as expected given that in GIMP "save" is only for XCF files) "The given filename cannot be used for saving", followed by "You can use this dialog to save to the GIMP XCF format. Use File→Export to export to other file formats."
This seems like a bug. It would be preferable if the dialog for saving the decomposed layer stack would just automatically use ".xcf" as the suggested file extension, instead of unhelpfully suggesting a non-supported file type for saving the layer stack.
This is for 2.10 and also for 2.99. The behavior also affects newly imported jpegs that haven't been saved as xcf files, and so likely affects all other "imported but not already saved as xcf" files.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/3471Unexpected results for luma darken only2024-01-30T12:44:41ZElle StoneUnexpected results for luma darken onlyThis is for GIMP-2.10 and also for GIMP-2.99. In the attached XCF file, there are three layers. The layer masks are set up so that Sample point 1 always samples from the top layer, and Sample point 2 always samples from the middle layer....This is for GIMP-2.10 and also for GIMP-2.99. In the attached XCF file, there are three layers. The layer masks are set up so that Sample point 1 always samples from the top layer, and Sample point 2 always samples from the middle layer. There is a selection around Sample point 1 just to show visually where it is:
[luma-darken-lighten-test-auto-or-perceptual-blend.xcf](/uploads/716c19eabb4e4d8d45a4501eeaf034a8/luma-darken-lighten-test-auto-or-perceptual-blend.xcf)
Here's a screenshot showing the above XCF file (on the right), and a duplicate of the XCF file (on the left), along with the layer stack and the Sample points:
![luma-darken-blend-odd-results](/uploads/93b1d302f0d0c1af1e158f473dadfd9c/luma-darken-blend-odd-results.png)
Notice that Sample point 1 has a "Y" value of 0.145418, and Sample point 2 has a higher Y value of 0.184187. So if the top layer is set to "Luma darken only" one would expect that all but the square around Sample point 2 would be the color of the top layer. But the only way to make this happen is to right-click on the top layer and change the layer blend mode from "Auto" to "linear", which the only way the XCF file on the left in the screenshot differs from the XCF file on the right.
For the Luma lighten and Luma darken layer blends to make intuitive sense, It seems to me that "Luma" needs to be replaced with "Luminance" and the operations need to always (or rather "by default") work on linear RGB. Otherwise the user will be very puzzled as to why a darker shade of brown is somehow "lighter" than a lighter shade of red.3.0 RC1JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/3247Brush angles are wrong, mirrored2024-02-11T15:04:20ZGhost UserBrush angles are wrong, mirroredGIMP version: 2.10.10
Operating System: Win 10
Package: Installer from gimp.org
# Description of the bug
Brush angles are wrong.
Brush angles are mirrored along the x axis.
Brush angles are negative to their actual values in the Tool...GIMP version: 2.10.10
Operating System: Win 10
Package: Installer from gimp.org
# Description of the bug
Brush angles are wrong.
Brush angles are mirrored along the x axis.
Brush angles are negative to their actual values in the Tool Options.
Brush angles are negative to their actual values in the Brushes window.
# Reproduction
Is the bug reproducible? Always.
Reproduction steps:
1. make a new brush.
2. give it aspect ratio and angle, like in the screen shot.
3. the brush angle is actually wrong compared to what it should be.
…
Expected result: brush angle should match the preview.
Actual result: brush angle is wrong![image](/uploads/9facb0eeafabd2f7fe2cb9cf3208e186/image.png)3.0 RC1Alx SaAlx Sahttps://gitlab.gnome.org/GNOME/gimp/-/issues/3015Space invasion: Using Levels Pick white point for all channels doesn't work2024-03-25T23:11:08ZElle StoneSpace invasion: Using Levels Pick white point for all channels doesn't workUsing babl/GEGL/GIMP-2.99 updated this morning (Feb. 25, 2019), I opened a raw file using darktable. The raw file can be downloaded here:
https://pixls-discuss.s3.dualstack.us-east-1.amazonaws.com/original/3X/b/1/b163031f570f80eb5ca3d10...Using babl/GEGL/GIMP-2.99 updated this morning (Feb. 25, 2019), I opened a raw file using darktable. The raw file can be downloaded here:
https://pixls-discuss.s3.dualstack.us-east-1.amazonaws.com/original/3X/b/1/b163031f570f80eb5ca3d100a5d3504380decb94.cr2
In darktable, *no* processing was done other than the actual interpolation. In particular, the raw file wasn't white-balanced, so the multipliers were "1,1,1,1" and the resulting image looks blue-greenish. The reason for not white balancing the raw file was to make a sample file for testing the possibility of white balancing an image in GIMP after converting to a suitable RGB working space, in this case a working space based on the camera profile (white balancing in sRGB produces garbage in such cases, as explained here: https://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html).
No matter what combination of precision conversions I tried - first for the conversion from GIMP sRGB to "CameraRGB", and then for the actual white balancing using Levels, I wasn't able to open the interpolated raw file (whether opened directly using darktable or else saved to disk as a 32f tiff or exr and then opened using darktable), convert it to the appropriate color space, and then use Levels to white balance the image. Results were identical for all the combinations (or at least appeared identical, the red channel value was very negative, on the order of -35), regardless of the various combinations of precision changes.
Here's a screenshot showing the properly white balanced image in my GIMP-CCE (bottom image), and the result in GIMP-2.99 (top image):
![gimp299-Levels-white-balance-fails](/uploads/15e958ada3468e75660c73cc2d62312e/gimp299-Levels-white-balance-fails.png)
As an aside, the top two layers in GIMP-2.99 layer stack (on the left side of the screen shot) were to verify that white balancing by division still does work, which in fact it does. But white balancing by division is not something most users are going to even know how to do.
My apologies if I already filed a bug report on the inability to white balance post-space-invasion using Levels/Pick white point for all channels.
This is on Debian Sid, fwiw.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/2933LCh Chroma blend over gray: net Lightness of underlying layers determines ble...2024-02-11T15:14:47ZElle StoneLCh Chroma blend over gray: net Lightness of underlying layers determines blended colorThis issue affects GIMP-2.99 and also GIMP-2.10. Tested on Debian Sid using babl/GEGL/GIMP updated yesterday.
The net Lightness of an underlying neutral gray layer determines the resulting color when using LCh Chroma blend for an overly...This issue affects GIMP-2.99 and also GIMP-2.10. Tested on Debian Sid using babl/GEGL/GIMP updated yesterday.
The net Lightness of an underlying neutral gray layer determines the resulting color when using LCh Chroma blend for an overlying color layer. There are two possible "correct" results, neither of which are actually happening:
* The "by definition" correct behavior is that in all cases when blending a color layer set to Chroma blend mode over neutral gray, the resulting color should have L=L of the underlying layer, C=Chroma of the top layer, and h=0/360 (magenta-red) because the hue of gray is indeterminate.
* The "better for editing" behavior, which I think is already programmed into babl, is that a color layer blended with neutral gray using Chroma blend mode should remain neutral gray, C=0.
The screenshot below shows two basically identical layer stacks, one created and open in GIMP-2.99, then other created and opened in GIMP-2.10. In both cases the bottom layer is solid white, the middle layer is solid black, and the top layer is Cyan, with the LCh values L=70, C=45, h=180. The only difference in the layer stacks is the opacity of the black layer, which is 100% for GIMP-2.10 and 64.6% for GIMP-2.99.
As set up, the layer stacks allow (and the screenshot below shows) two easy ways to vary the net Lightness: either by varying the opacity of the black layer, or by using Curves to change the Lightness of the black layer. Both ways can be used in both versions of GIMP with essentially the same results: The resulting blended color varies wildly from neutral/near-neutral gray (Chroma=0 or is very close to 0) to "colorful" colors of various hues, all with Chroma=45.
![for-chroma-blend-net-lightness-of-gray-determines-blended-color-in-both-299-and-210](/uploads/373d46166013d092d1c8761eb4421bc1/for-chroma-blend-net-lightness-of-gray-determines-blended-color-in-both-299-and-210.png)
In case anyone wants to check this behavior out for themselves, the attached XCF files are at 32f perceptual precision in GIMP's built-in sRGB color space. Similar results obtain when using 32f linear precision and also after converting to color spaces other than built-in sRGB, such as linear Rec.2020 from disk.
[gimp-210.xcf](/uploads/ae8f9d0d1de31046024551539cd79d69/gimp-210.xcf)
[gimp-299.xcf](/uploads/1081aa3a564114b212d4edf4d592adf2/gimp-299.xcf)
Of course in GIMP-2.10, converting to color spaces other than built-in sRGB produces wrong LCh values in general - not even the resulting L value is correct.
See also:
* https://gitlab.gnome.org/GNOME/gimp/issues/2592
* https://gitlab.gnome.org/GNOME/gimp/issues/29293.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/2929Toolbox "Change FG tool", sometimes LCh sliders can't be moved independently2024-03-24T15:45:27ZElle StoneToolbox "Change FG tool", sometimes LCh sliders can't be moved independentlyFor GIMP-2.99, when using the FG/BG tool to dial in a color, when starting with the LCh color L=C=h=0 (solid black, R=G=B=0):
* Dialing in L=50 (leaving the other channels alone) makes the LCh hue reset itself to h=142-ish.
* Resettin...For GIMP-2.99, when using the FG/BG tool to dial in a color, when starting with the LCh color L=C=h=0 (solid black, R=G=B=0):
* Dialing in L=50 (leaving the other channels alone) makes the LCh hue reset itself to h=142-ish.
* Resetting h to 0 and dialing in C=20, the hue again reset itself to a hue other than 0, on my last try it reset to 4.
* Going back and changing "L" makes the other sliders change again.
Similar oddities happen in GIMP-2.10, so this likely isn't a result of code changes for "anyrgb".
This "resetting" of the hue when changing the Lightness and Chroma absolutely shouldn't happen. And modifying L shouldn't also make one or both of the other LCh sliders move. It should be possible to start with solid black L=C=h=0, and dial in L=50, with C and h staying at 0. And then it should be possible to set C to a number greater than 0, and still have the hue stay at 0. In other words, modifying any one slider should *not* cause the other sliders to move.
The problem also affects the "FG/BG Color" docker sliders, though the exact numbers that pop up vary from the Toolbox Change Foreground tool. Also, in the FG/BG tool, sometimes moving the LCh sliders to be zero makes one or more of the RGB channels read as negative zero.
This slider resetting might be related to the problem that blending a top color layer using LCh Chroma over a bottom gray layer sometimes produces unexpected hue shifts. Note in the 2.10 screenshot below, the hue shift just from the blend - the Sample Points show the blended RGB and LCh. The color picker is set to only read the actual color layer rather than the merged result. Both color readouts should have the same hue and Chroma, but notice the blended hue is different from the hue of the actual layer:
![7](/uploads/2aa821d50323c98759a67ad71760d443/7.png)
This is on Debian Sid, updated today, and using babl/GEGL/both versions of GIMP also updated today.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/160Transforms to selections do not translate to selected layers2024-02-04T10:38:33ZBugzillaTransforms to selections do not translate to selected layers## Submitted by Reuben
**[Link to original bug (#315308)](https://bugzilla.gnome.org/show_bug.cgi?id=315308)**
## Description
1) Create two layers.
2) Link them.
3) Make a selection on one of the linked layers.
4) Apply a transform ...## Submitted by Reuben
**[Link to original bug (#315308)](https://bugzilla.gnome.org/show_bug.cgi?id=315308)**
## Description
1) Create two layers.
2) Link them.
3) Make a selection on one of the linked layers.
4) Apply a transform to the selction. (rotate for instace)
What happens: The transform is applied to the selection of the current layer
while the rest of the layer is untouched. However, the transform is applied to
the linked layer as a whole.
What should happen: The transform applied to the linked layer(s) should only
apply to the selected area as it does in the current layer.
Version: 2.2.x3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10932Rename procedures file-*-save as file-*-export2024-02-27T10:46:27ZJehanRename procedures file-*-save as file-*-exportI suddenly remembered that we had discussed that we want to rename all the export procedure as '-export' for consistency, some time ago on IRC. Opening this report for not forgetting (after GIMP 3, it'll be too late).I suddenly remembered that we had discussed that we want to rename all the export procedure as '-export' for consistency, some time ago on IRC. Opening this report for not forgetting (after GIMP 3, it'll be too late).3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10922About the future of 32-bit2024-02-25T17:11:02ZBruno LopesAbout the future of 32-bitAfter #10666, it seems like the siege is closing day after day against our 32-bit build 😅.
32-bit lua-lgi was dropped some days ago by the MSYS2 guys:
https://github.com/msys2/MINGW-packages/commit/93f22f99e2471f54103ba6e285e2f1c86f7766...After #10666, it seems like the siege is closing day after day against our 32-bit build 😅.
32-bit lua-lgi was dropped some days ago by the MSYS2 guys:
https://github.com/msys2/MINGW-packages/commit/93f22f99e2471f54103ba6e285e2f1c86f7766f2#diff-6a773edb90ff26b85cc0c6742490a51aa43712a1077297f7cd622c73f8cb3060
This is making our x86 runner [fail](https://gitlab.gnome.org/GNOME/gimp/-/jobs/3610396#L229) again:
```
error: target not found: mingw-w64-i686-lua51-lgi
```
/cc @Jehan @Wormnest @jernejs
---
I don't have the authority to talk about this (I am still researching the 32-bit issues in our tracker) and was planning to postpone this for after 3.0, but our I would like to point the following complications with the 32-bit build (not all of them have the same weight):
#### Maintenance drawbacks:
- The 32-bit crossbuild requires non-binary parts of the x64 artifact to work. This little detail makes scripting [a bit complicated](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/build/windows/gitlab-ci/2_build-gimp-crossroad.sh#L47), even this being now a custom GUI build.
- Actually, we have two Creiter runners, one for each arch. Thi
- If we don't want to [bother](https://github.com/msys2/MINGW-packages/discussions/19326#discussioncomment-8522654) MSYS contributors, we'll need to add more custom builds but when we fix a CI bug another 32-bit one appears. This can make some Windows contributors feeling exhausted by needing to go that far for 32-bit.
#### Consistency drawbacks:
- The native x64 build [can't be run](https://gitlab.gnome.org/GNOME/gimp/-/issues/1159) when Restriction Policy is enabled on Windows because of 32-bit TWAIN plug-in binaries. This limits the user's security options
- The above point is more imminent than it may seem. The MSIX package for ARM64, due to Microsoft limitations, [willn't have](https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1154) the 32-bit TWAIN plug-in. This will make some (few) ARM users blame the store version
- The 32-bit build suffers from specially inherent limitations, for example: it [can't do](https://gitlab.gnome.org/GNOME/gimp/-/issues/5301) simple actions like opening a "big" file. This makes GIMP appear somewhat "buggy".
Finally, I would like to point out that if we dropped the 32-bit build this would not be so damaging to the "userbase" as there is no alternative other than GIMP. Krita and paint.net have already dropped this architecture.
Of course, the ancient TWAIN plug-in will be mostly useless, but [it's not like](https://gitlab.gnome.org/GNOME/gimp/-/issues/84) the plug-in was that reliable or popular.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10875Welcome dialog: additional customization options are very close together2024-03-18T16:23:48ZJacob BoeremaWelcome dialog: additional customization options are very close together### Environment/Versions
- GIMP version: current master self-built on Windows 10
### Description of the bug
In the welcome dialog, the two additional customizations are next to each other with not much space in between. Other language...### Environment/Versions
- GIMP version: current master self-built on Windows 10
### Description of the bug
In the welcome dialog, the two additional customizations are next to each other with not much space in between. Other languages often require more text, which is solved by moving the second option and if needed widening the dialog.
However:
- It might be easy to overlook the second option because they are so close together.
- If a translation needs a lot more space, the dialog might get wider than desirable.
Maybe we should consider another layout for these two options. One problem might be that the height is already almost as high as the height of a small 1360x768 screen.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/108612.99 van Gogh doesn't work without first selecting an image2024-02-16T02:54:47ZJacob Boerema2.99 van Gogh doesn't work without first selecting an image### Environment/Versions
- GIMP version: self-built master on Windows 10, 64-bit
### Description of the bug
After opening an image and selecting the van Gogh filter and pressing OK without changing anything, nothing happens.
In 2.10....### Environment/Versions
- GIMP version: self-built master on Windows 10, 64-bit
### Description of the bug
After opening an image and selecting the van Gogh filter and pressing OK without changing anything, nothing happens.
In 2.10.36 there was always an image selected and pressing OK did work. It seems that now we need to have an image selected or the plug-in doesn't work.
We should either:
- Make sure there is always an image selected,
- or Give a warning message when pressing ok with no image selected.
I don't think this is that urgent, so setting 3.0RC1 milestone.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/108552.99 API: enhance: eliminate type "uchar" in pdbgen2024-02-16T21:26:00ZLloyd Konnekerkonnekerl@gmail.com2.99 API: enhance: eliminate type "uchar" in pdbgenThe type is not supported in GimpProcedureConfig, so any PDB procedure declared having an arg of PDB type "uchar" fails.
We are eliminating the uses of the type in a very few PDB procedures in the repo. Then the support for the type i...The type is not supported in GimpProcedureConfig, so any PDB procedure declared having an arg of PDB type "uchar" fails.
We are eliminating the uses of the type in a very few PDB procedures in the repo. Then the support for the type in pdbgen (the code generator tool) is cruft which can be deleted, as cleanup. Prevents it from being used in the future.
Alternatively, keep the PBD type and change libgimpconfig to support 8-bit arguments to PDB procedures.
The change is to delete one paragraph in pdb/pdb.pl
More discussion at #10833 !13353.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10715Icon for effect GUI2024-02-13T22:59:34ZJehanIcon for effect GUI@aryeom Could you upload a small icon to be used for effects, as in https://developer.gimp.org/core/specifications/layer-effects-ui/ ?
Thanks.@aryeom Could you upload a small icon to be used for effects, as in https://developer.gimp.org/core/specifications/layer-effects-ui/ ?
Thanks.3.0 RC1AryeomAryeomhttps://gitlab.gnome.org/GNOME/gimp/-/issues/10713Check API versionning before GIMP 3 release2024-03-07T13:41:50ZJehanCheck API versionning before GIMP 3 releaseSee: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1298#note_1984105
It looks like our versionning scheme may have been broken with the meson port. Look more closely into it and decide if we want to get back to 2.10 or if there w...See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1298#note_1984105
It looks like our versionning scheme may have been broken with the meson port. Look more closely into it and decide if we want to get back to 2.10 or if there was any reason to change it.3.0 RC1JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/10471gimp_edit_copy(): doesn't behave like docs or 2.102024-03-21T17:10:22ZLloyd Konnekerkonnekerl@gmail.comgimp_edit_copy(): doesn't behave like docs or 2.10Possibly this is just a reminder to update the docs.
### Reproduction
1. Starting fresh GIMP, open wilber.png
2. Enlarge the canvas
3. Drag out a selection off the layer, but in the canvas, say in lower right, in the checkerboard area....Possibly this is just a reminder to update the docs.
### Reproduction
1. Starting fresh GIMP, open wilber.png
2. Enlarge the canvas
3. Drag out a selection off the layer, but in the canvas, say in lower right, in the checkerboard area.
4. In the SF Console (gimp-edit-copy 1 #(2)) meaning copy the selection out of layer with ID 2.
Expected result: SF Console prints (0) meaning boolean result is false.
Actual result: prints (1)
Per the PDB Browser, which says " This procedure will fail if the selected area lies completely outside the bounds of the current drawables and there is nothing to copy from."
BTW, it should say "procedure will return false..." since the procedure can fail harder: the PDB procedure failed to return anything.
You can probably reproduce without using the ScriptFu Console. Choose Edit>Copy. Then Edit>Paste should remain disabled i.e. greyed out because the copy failed to put anything on the clipboard? But its not disabled, and if e.g. you choose Edit>PasteAs>NewImage you get a new image that seems devoid of pixels.
### Additional information
Behaves differently in 2.10, similar steps do print (0).
If the change in behavior is intended, the annotations for the PDB procedure need updating.
Otherwise, a bug.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10322Refreshing the templaterc2024-02-24T11:23:28Znb1Refreshing the templaterc**Operating System:** All
### Description of the feature
Templates for new image contains old and unnecessary items. This is a new refreshed list.
There are several other feature requests regarding a more complete redesign :
- #7160 T...**Operating System:** All
### Description of the feature
Templates for new image contains old and unnecessary items. This is a new refreshed list.
There are several other feature requests regarding a more complete redesign :
- #7160 Templates like in Krita
- #852 Make templaterc file translatable
But this change is easy and could be implemented before a new redesign.
To make a good impression, this is also the one of the first things a new user see after launcher GIMP. For the next GIMP 3.0, it will be weird to still see iPhone 5/6 (10-11 years) and Samsung Galaxy S5/S6 (9-10 years).
### Changes
- Updated top used ad banners
- Updated top used display screen (with standard)
- Updated top used phone scale
- New top used social cover
- Updated CD front fixed to be square and CD back added
| Actual templaterc | Proposed templaterc |
| ------ | ------ |
| A0 (300 ppi) | A0 (300 ppi) |
| A1 (300 ppi) | A1 (300 ppi) |
| A2 (300 ppi) | A2 (300 ppi) |
| A3 (300 ppi) | A3 (300 ppi) |
| A4 (300 ppi) | A4 (300 ppi) |
| A5 (300 ppi) | A5 (300 ppi) |
| A6 (300 ppi) | A6 (300 ppi) |
| A7 (300 ppi) | A7 (300 ppi) |
| B4 (300 ppi) | B4 (300 ppi) |
| B5 (300 ppi) | B5 (300 ppi) |
| B5-Japan (300 ppi) | B5-Japan (300 ppi) |
| US Letter (300 ppi) | US Letter (300 ppi) |
| US Legal (300 ppi) | US Legal (300 ppi) |
| 88.9×50.8 US Business Card | 88.9×50.8 US Business Card |
| 85×55 Western Europe Business Card | 85×55 Western Europe Business Card |
| 90×50 Eastern Europe Business Card | 90×50 Eastern Europe Business Card |
| 90×55 Business Card (AU, IN etc.) | 90×55 Business Card (AU, IN etc.) |
| 87×49 Vistaprint Business Card | 87×49 Vistaprint Business Card |
| Toilet paper (US, 300 ppi) | Toilet paper (US, 300 ppi) |
| CD cover (300 ppi) | CD front cover (300 ppi) |
| Web banner leaderboard 728x90 | CD back cover (300 ppi) |
| Web banner large rectangle 336×280 | Web profile / avatar / icon 512×512 |
| Web banner medium rectangle 300×250 | Web cover Facebook 820×312 |
| Web banner large mobile 320×100 | Web cover X/Twitter 1500×500 |
| Web banner large skyscraper 300×600 | Web cover Youtube 2560×1440 |
| 1280×720 (HD 720p) | Web banner leaderboard 728×90 |
| 1920×1080 (Full HD 1080p) | Web banner half page 300×600 |
| 3840x2160 (4K UHD) | Web banner medium rectangle 300×250 |
| 4096×2160 (Digital Cinema Initiatives 4K) | Web banner wide skyscraper 160×600 |
| 1366×768 HD | Web banner mobile leaderboard 320×50 |
| 1920×1200 WUXGA | Display - 4:3 - 640×480 (VGA) |
| 2560x1600 WQXGA | Display - 4:3 - 800×600 (SVGA) |
| 3840×2160 4K UHD | Display - 4:3 - 1024×768 (XGA) |
| Apple iPhone 6/7 | Display - 4:3 - 1152×864 (XGA+) |
| Apple iPhone 5 | Display - 4:3 - 1600×1200 (UXGA) |
| Apple iPad 3&4, Air | Display - 4:3 - 2048×1536 (QXGA) |
| Samsung Galaxy S6 | Display - 16:10 - 1680×1050 (WSXGA+) |
| Samsung Galaxy S5 | Display - 16:10 - 1920×1200 (WUXGA) |
| Samsung Galaxy Tab 2&3 10,1 inch | Display - 16:10 - 2560×1600 (WQXGA) |
| | Display - 16:10 - 3840×2400 (WQUXGA) |
| | Display - 16:9 - 1280×720 (HD 720p) |
| | Display - 16:9 - 1920×1080 (Full HD 1080p) |
| | Display - 16:9 - 3840×2160 (4K UHD) |
| | Display - 16:9 - 7680×4320 (8K UHD) |
| | Display - 17:9 - 2048×1080 (DCI 2K) |
| | Display - 17:9 - 4096×2160 (DCI 4K) |
| | Phone - 18.5:9 - 1440×2950 |
| | Phone - 19:9 - 1440×3040 |
| | Phone - 19.5:9 - 1080×2340 |
| | Phone - 19.5:9 - 1284×2778 |
| | Phone - 20:9 - 1080×2400 |
| | Phone - 20:9 - 1440×3200 |
Do you have any comments or suggestions for others improvements?
- May be Toilet paper and CDs could be placed at the bottom of the list, less frequent use ?
- I'm not sure for "640×480 (VGA)" and "800×600 (SVGA)" if it's really important in 2023 ? Maybe for retro stuff ?
- I use 300ppi in general for the xcf to have a high def working base document, and after reduce the quality if necessary in export, so must of the quality here have been augmented. Seems right ?
### Files
[templaterc](/uploads/9652c9e6fcda2491f8c09a850c89854c/templaterc)
[0001-Refresh-templaterc.patch](/uploads/1bc1de371ac22b770486620109a043bc/0001-Refresh-templaterc.patch)3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/9947[TRACKING] Space Invasion in GIMP 32024-03-20T04:22:34ZJehan[TRACKING] Space Invasion in GIMP 3This is a catch-all TODO-list for all the remaining points I want us to handle regarding color invasion in GIMP 3. Basically the goal is not to add new features but make sure that existing features produce good results and that various c...This is a catch-all TODO-list for all the remaining points I want us to handle regarding color invasion in GIMP 3. Basically the goal is not to add new features but make sure that existing features produce good results and that various color-related features are color-generic:
- [x] Color picking should pick in the input image color space (#7898)
- [ ] Color view widgets should store colors in the source color space (e.g. in case of colors picked from an image, the non-converted original color and color space should be stored) and displayed in the display space.
- [ ] When relevant, color view widgets should be contextual (relatively to the active image), either by showing an out-of-gamut indication when relevant (while showing colors in display space even when out-of-gamut) or by converting colors to the active image's space (possibly truncating to gamut).
- [ ] Color selection in Colors dockable should have both generic space selection methods and selection relative to the active image.
- [x] Palette should store input colors and space as-is too (cf. https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/843#note_1838225).
- [ ] In-GIMP color palette creation should also be color-space aware.
- [ ] Make a decision regarding color space conversions at image loading (cf. #8494). Probably doing nothing (i.e. keeping the color space as-is) should be the new default.
- [ ] Basic color management and soft-proofing should be verified (#8107 and #8269).
- [ ] Out-of-gamut on-canvas handling to be improved (#8381)
- [ ] All blend/composite modes algorithms should be verified for bugs.
- [ ] Review GUI for blend/composite modes to be more explicit while simpler to use; also we should check if it is possible for the Legacy modes to be converted to one of the new modes variant (#3901).
- [ ] Usage of GimpRGB everywhere should be replaced either by GeglColor or by a new GimpColor which should be generic and extensible. This should happen both in core and libgimp.
- [ ] The layer mode GUI must be updated to make blend/composite space/modes editing much more obvious and usable. (#3901)
- [ ] Blend Space perceptual seems broken with a non-perceptual imaged as what it does (didn't look at the code, just guessing) is actually to just work within the image space. So an "Addition" will just add layer values in whatever is the image space. In other words, if your image is stored linearly, it works the same in linear and perceptual blend space (obviously wrong) and worse, if you change your image encoding (e.g. convert to sRGB), the rendering will change! [pretty sure there was a report about this, but I can't find it anymore]
This list is meant to be extended, edited, amended as we go. Some parts of this list are already done in parts. Other non-listed items were also already implemented in the previous years. I have not added things which already work.3.0 RC1JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/9477gimp_image_*_colormap*() functions have a problematic signature for introspec...2024-03-21T23:46:28ZNiels De Graefnielsdegraef@gmail.comgimp_image_*_colormap*() functions have a problematic signature for introspectionWhen creating !921, I noticed that the `gimp_image_get_colormap()` and `gimp_image_set_colormap()` have several issues:
* They return/accept an array of raw bytes, which needs to have a `size` argument to be properly introspectable. The...When creating !921, I noticed that the `gimp_image_get_colormap()` and `gimp_image_set_colormap()` have several issues:
* They return/accept an array of raw bytes, which needs to have a `size` argument to be properly introspectable. They don't have that, but a `num_colors` argument instead which is then supposed to be multiplied by 3 to get the actual number bytes. Bindings can't know this though
* It assumes that it can only have RGB888 format (no alpha, no higher bit depth)
* Returning a `uint8` is not really semantically useful
Possible solutions:
* ~~Return/Accept a `GimpRGB` array instead of raw bytes, so that the length argument works out for bindings too~~
* ~~Create a `GimpColorMap` object, which then also allows to have extra methods that are now distributed over multiple methods in GimpImage (e.g. gimp_image_get_colormap_size() or gimp_image_get_colormap_entry())~~
EDIT:
Actually, I talked to @simon and it would be better to remove this API in favor of using the `get_palette()` methods3.0 RC1JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/9322MacOS menu integration regression after full port to GTK 32024-01-31T14:42:41ZLukas OberhuberMacOS menu integration regression after full port to GTK 3### Environment/Versions
- GIMP version: 2.99.15 gtk3 version
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> development
- Operating System: <!--[Windows? mac...### Environment/Versions
- GIMP version: 2.99.15 gtk3 version
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> development
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> macOS
<!--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)-->
MacOS menu usage has regressed from 2.99.14 post integrating the full upgrade to GTK3. See https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/837
The issues are:
1. GIMP menu does not match macOS expectations:
a. `Settings...` menu item is called `Preferences` (and smaller issue: does not have a shortcut, which should be Command+`,`)
b. `Hide GIMP`, `Hide Others` and `Show All` menu items are missing
Standard 2.99.x:
![image](/uploads/41c7f1db86acd2fb8b64039fedc7867e/image.png)
Gtk3:
![image](/uploads/f7cd3722367692bcfc94d1360371cc83/image.png)
2. File menu: the Quit item should not appear here. Also I've noticed the order of some of the items has changed from `master` version. Don't know if intentional or not.
Gtk3:
![image](/uploads/dc661db1ae32415cb22ae9cdabb9a94b/image.png)
3. Edit menu: Preferences, Keyboard Shortcuts and Input Devices should not appear here. Since you've removed Modules and Units from `GIMP` menu, makes sense for them to be here. Manage extensions is in a different place here.
Gtk3:
![image](/uploads/2c8534fb7cfe50fc61c384d1b275192a/image.png)
4. Windows and Help menus should be last two menus.
Gtk3:
![image](/uploads/36f3664244c21956826a4cf48171dc7a/image.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. NA
…
Expected result: See screenshots
Actual result: See screenshots3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/9270Change GimpBrushSelect to choose only brush in app/widgets2024-03-27T21:51:29ZLloyd Konnekerkonnekerl@gmail.comChange GimpBrushSelect to choose only brush in app/widgetsThis is a reminder to finish work started with !740, !771, and !786 related to GimpResource on the libgimp side.
Its a bug now, because of enhancement in progress.
The widget is a dialog in app/widgets/gimpresourceselect.c.
It is a remo...This is a reminder to finish work started with !740, !771, and !786 related to GimpResource on the libgimp side.
Its a bug now, because of enhancement in progress.
The widget is a dialog in app/widgets/gimpresourceselect.c.
It is a remote widget used only (?) by plugins.
It is on the app side because the app knows the set of installed resources such as brush.
Libgimp and plugins have GimpResourceSelectButton's that popup this widget.
Currently, the widget lets a user choose a brush, spacing, and opacity.
It should only let the user choose a brush.
(Like the widgets for font, gradient, pallete, pattern.)
There is discussion in #8724, which proposed something else
(a LoadedBrush or StyledBrush concept, meaning the tuple of brush, spacing, opacity.)
Currently, the widget callbacks across the wire for any change to brush, spacing, opacity.
This is known to crash when user touches e.g. spacing.
(Because the earlier MR's left this unfinished.)
The widget should only callback when a brush is changed.
The wire protocol should change to only pass the brush ID.
The app side currently passes brush, spacing, opacity, but should not.
The libgimp side of the protocol currently ignores the other passed values.
The libgimp side should be simplified, it won't need to ignore values.
Any plugins (e.g. GFig) that let the user choose spacing and opacity
will need to have additional widgets (simple, primitive valued widgets)
to choose spacing and opacity.
I don't think this affects the widgets for font, gradient, palette, pattern,
but that should be checked.
Also check that ScriptFu in its own implementation of GUI and registration for SF-BRUSH
does not traffic in spacing and opacity.
Check that no plugins (ScriptFu or otherwise)
still rely on the old widget trafficing in spacing and opacity.
Update the ScriptFu docs re SF-BRUSH.3.0 RC1