gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
In case of negative y in the region to process, we were accessing invalid memory
(negative array index).
I hesitated between make so that a given ordinate always use the same index or
if we just want the start ordinate (whatever it is) to use index 0. The later
could have just been `(y - result->y) % RANDOM_TABLE_SIZE`.
I just decided to keep the existing logic (former case) though to be fair, not
sure it matters much.
While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
The magics used for detection for CUR and ICO are not very unique and
interfere with the detection of certain types of TGA images.
Since these TGA images are regularly used, it seems better to only base
CUR and ICO detection on the extension, just as we do with TGA version 1
files.
See also issue #7912
Krita had a bug where it incorrectly saved 4 for the alpha bits instead of
8. We will allow 4 and convert that to 8 to be able to read the incorrect
TGA images.
The likelyhood of real TGA images with 4 alphabits seems pretty low, so it
should not interfere with real images that have this set. We were not
supporting that anyway.
(cherry picked from commit 5f9415a641)
Added the 2 new PDB functions. I should not have added these so close to release
(because these add 2 translatable strings for undo), but anyway the added
strings are barely GUI-facing as these functions are for plug-in developers.
And I really wanted to finally review these MRs which have been sitting there
for months. Sorry translators!
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
Original issue: #8581
1. When an image with a non-xcf format is loaded, within GIMP core it
qualifies as an imported file. (See gimp_image_get_imported_file
function)
2. But the guillotine plugin cannot propagate this information.
It can only set the file path on the new image it creates, and it uses the file extension of the original imported file.
3. But since the filename is set by the plugin is the actual filename not imported filename,
the gimpsavedialog.c module cannot differentiate it. This results in the
incorrect file extension being set in the "gimp_save_dialog_set_image"
function.
This issue can actually be present in other plugins as well that
generate new images which has to be checked.
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
This implements the full fix to the problem noted in the prior commit.
While it no longer crasheed when applying a function after clearing the
console, Jehan reported it still showed a CRITICAL message. This should
fix it the same as the 2.99 branch.
GTK2 get_iter_at_line_offset() does not allow invalid offsets unlike
GTK3 version. Clearing the console creates an invalid iter due to an
empty buffer.
This patch attempts to resolve it by adding a ">>> " output when the
console is cleared, thus preventing the invalid iter issue.
This reverts commit 13284c8953.
Actually I should not have backported this change from the `master` branch.
These functions are still public in 2.10 (and internal in the main branch).
This should fix our CI.
A bug in babl would run the color conversion twice when the input and output
buffer is the same and a LUT is available for the color transform. This is a
workaround in GIMP code (especially because we still don't require the latest
babl version), though a real bug fix will soon happen too in babl itself as
well.
The defcheck.py file finds these errors:
> Problem found in /home/jehan/dev/src/gimp/libgimpwidgets/gimpwidgets.def
> the following symbols are listed in the .def-file,
> but are not exported by the library.
> - gimp_color_picker_cursors_get_resource
> - gimp_icon_pixbufs_get_resource
Indeed these don't exist. Unsure why the autootols check failed to
report these until today.
(cherry picked from commit 01e87819ce)
Some PDF have transparency on purpose. Filling with white, without any question,
is counter-productive and prevents from working on such PDF files.
Note that we could add an option with a checkbox, leaving one to decide whether
to fill the background or not. But it feels over-engineering the issue. The PDF
is transparent, so that's what we load, and that's it. If one wants to add a
background, it's easy to add a layer at the bottom of the stack (and they can
make it any color they want, not just white), after loading the file.
(cherry picked from commit c369827725)
I had a TIFF file which would crash while triggering an error, inside g_logv()
code (and according to the stacktrace, even probably inside some lower level
printf implementation code).
The reason was that I already processed the variable list with
g_strdup_vprintf() and printf didn't like this va_list being reused, then
segfaulted with some "Cannot access memory at address" error.
The alternate fix was to first copy the va_list in the first use with
va_copy()/G_VA_COPY, yet since we already processed the format data, I thought
it was useless to do this. Let's just directly use the formatted string.
(cherry picked from commit fb1f16d4b8)
