Resolves#14966
When "Include mouse pointer" is checked in the Windows
version of the Create Screenshot plug-in, we used the
GetCursor () Win32 API to get the cursor icon. However,
this just returns a generic cursor rather than the current one
used.
This patch changes the code to use the hCursor property of
the CursorInfo struct that was already retrieved, which contains
the current cursor's icon instead of the generic one.
While listing the file formats, I could not find the format, because it
was labelled differently.
This doesn't break the strings since the longer string already existed.
Since libgimpui also use GIMP_ as prefix in C, we won't ever have name
clashing with libgimp, so I also remove this prefix in Script-Fu.
E.g. GIMP_ASPECT_SQUARE is ASPECT-SQUARE in Script-Fu.
It is possible for qbist_info.path to be NULL, which
makes gtk_file_chooser_set_filename () throw a warning
about a NULL filename in save_dialog ().
This patch adds the same guard to that call as QBist
already has in load_dialog (), to make sure we have
an existing file name before trying to set it.
This fixes Spyro Plus not running interactively after commit a7f02d4ee1.
Note that this seems to be the only plug-in which got broken by this
commit AFAICS.
The create guides dialog of the imagemap plug-in shows up very wide
due to the hint text not being wrapped.
To fix this we enclose the hint box inside a scrolled window and set
horizontal policy to GTK_POLICY_EXTERNAL and a minimum vertical size
of 100, based on how we do this in the export procedure dialog for
the comment field.
This fixes this unharmful message we were getting on macOS CI:
Gdk-WARNING **: 18:06:23.048: Failed to initialize CVDisplayLink!
The hard ones (spyro-plus.py, histogram-export.py and python-console.py)
were not touched for now, just the ProcedureDialog plugins were fixed.
This patch adds a parasite on load that retains
the original import settings of a DDS
texture (such as compression, number of mipmaps,
and flags). This parasite is then checked on export,
and if it exists, we default the compression
format to the original to reduce the chance
the user will choose the wrong format for
the game they're creating the texture for.
The other data stored is not currently used,
but can be implemented in future commits.
We use Richard Geldreich's bc7enc_rdo
library to minimize the code changes required
in the existing DDS plug-in, and so it can
more easily be swapped out in the future.
In GIMP up to 2.10, the default color for the Fog filter
had linear RGB values (240, 180, 70), (#f0b446).
The set_rgba call that's now in Fog treated these normalized
values as sRGB, resulting in another, lighter color (#f8db8e).
Change to recalculated values from the definition at
https://en.wikipedia.org/wiki/SRGB to get the original color
again.
When we call (gimp-context-set-defaults) in the
Round Corners script, we reset the background color
in addition to temporarily clearing out the other
context settings. This results in us always using the
default white background color for the "Add background"
toggle.
This patch saves the background color beforehand and
restores it before creating the background layer, so we
still use the user's preferred color for this layer.
There was a report on reddit that the flare files on Windows were
stored with Windows (\r\n) line endings and that gradient flare did
not recognize these flare files.
Since these files are text files there is no reason not to accept
windows line endings. To do this, we adjust the header to not include
the line feed and check for the header as a prefix instead of the
whole line including line ending.
Also adjust saving to add the line feed separately.
when loading a specially crafted PSD.
After fixing the issue in the previous commit, using the poc from that
issue, a new issue surfaced where the ptr_array used for
img_a->alpha_name did not contain any names. Trying to access the
first index then caused a crash, because apparently that is only
valid if at least one item has been added.
Let's fix this by only creating the ptr_array when we know for sure
that we are going to add an item.
in fread_pascal_string
In plug-ins/file-psd/psd-util.c, the function fread_pascal_string()
allocates a buffer with g_malloc(len) and reads len bytes from the file
into it. The buffer is not null-terminated, but is assumed to be in
later code.
This causes it to read past the end of its allocated region with a
specially crafted PSD, causing a heap-buffer-overflow.
Fix this by alloocating one more byte than its length and set that
to '\0'.
When opening a saved gfig file that came with GIMP, I noticed
several criticals:
GEGL-CRITICAL **: 09:16:16.320: gegl_color_get_format: assertion
'GEGL_IS_COLOR (color)' failed
After that the gfig plug-in crashed.
After examination I noticed that the initial style gets copied. In
the case of the default style this means the source and destination
are the same.
When duplicating our code first removed the GEGL color objects from
the destination style before assigning from the source. But because
they are the same, this leads to invalid colors. Before the change
to GEGL colors they were simple values where reassigning didn't matter,
but here it does.
Since the same function does other assignments with resources that
may cause later issues, let's just return right away if the source
and destination style are the same.
Resolves#15814
As noted by JungWoo Park, since in fread_unicode_string ()
we read in a 32 byte value and then attempt to allocate
double the memory, we run the risk of overflowing and crashing
at g_malloc ().
This patch converts that function to g_try_malloc () and checks
if it returns NULL before going further.
file with INT16_MIN layer count
In PSD files the layer count is a 16-bit int that can be negative.
A negative value is a flag for transparency.
In our code, after setting the flag, we negate the value. However for
-32768 the minimum possible value, there is not 16-bit positive value,
so the value stays negative. This can cause a heap allocation failure
when we use this value to allocate memory.
To fix this, we check if the value is G_MININT16 and error out in that
case.
With an older configuration of a last run from before the new args had
been implemented, Curve Bend plug-in was crashing at start. The various
"*-point-*" argument were serialized as: (upper-point-x 0)
That meant an array of size 0 and that was enough to have the variable
load_settings_data set to 0 and therefore settings-data (which had the
real data) was never deserialized.
Previously, we serialize/deserialized the curve values in the
"settings-data" GBytes parameters, ignoring the specific parameters
created for the procedure.
This patch adds code to check if they exist (non-interactively) and
loads them from the *-point-* and *-val-* parameters. Otherwise,
the "settings-data" parameter is used for backwards compatibility.
Going forward, the relevant curve values are stored in the individual
parameters rather than "settings-data", so that we're ready to remove
that parameter in GIMP 4.0. A deprecation warning has been added
to make sure we don't miss it.
Removes the orig_list and orig_layers variables to simplify the export code, as these are
not used anymore, and advances the list variable to iterate through the layers list. Also
fixes a debug output line to make building with #define XMC_DEBUG work again.
Fixes issue #15645.
Leading to Heap Corruption
An integer overflow vulnerability has been identified in the PSP
(Paint Shop Pro) file parser of GIMP. The issue occurs in the
read_creator_block() function, where the Creator metadata block is
processed. Specifically, a 32-bit length value read from the file is
used directly for memory allocation without proper validation.
Trigger -> when length is set to 0xFFFFFFFF
To fix this, we check that using that length doesn't exceed the end
of the creator block. If it does, we return with an error message.
Our ICNS importer did not verify that the ICNS resource
data size was defined as larger than 0. Therefore, it
was possible to create a malicious file that would infinitely
load since the file cursor would not advance. This patch
adds a check for the icon size being 0, and stops the loop
if this is encountered.
Additionally, there is no header defined limit for the number of
icons in an ICNS file. This patch switches from using a hardcoded
256 icon limit to using GLists to dynamically add icons as we read
them in.
Following 2ce3c604 (for Windows) and d56676a2 (for Linux)
To make this possible the generate_mime_ext.py internals were
changed to construct a dictionary instead of a list like before,
because macOS supports both extension and mimetype (and also UTI).
We can't rely on python3 from shebang or python3 from .interp since
the found python by Meson can be python3.XX on MacPorts and Homebrew,
even with the PATH environment variable properly set.
Also, explains better the purpose of python 3 on relocatable builds.
Just like we did in commit 4eb106f2bf
we need to make sure that the offset in the colormap is valid before
using it, before using it to compute the RGB values.
Resolves#15684
In addition to setting the tcp_distoratio parameter to
the user's preferred quality, we also needed to enable
the cp_fixed_quality setting in OpenJPEG to actually
compress JPEG2000 images with different quality values.
Additionally, OpenJPEG expects the quality value to range
from 1.0 to 100.0, while we had it as 0.0 to 1.0. This patch
fixes both issues.
Some dropshadow offsets were incorrect when loading PSD's.
Photoshop has a global lighting angle that can override the angle
set for a dropshadow and we did not account for that.
This also showed that our computation of the X and Y values needed
to be adjusted.
Besides that I noticed a weird offset with angle values > 0xFF00 that
happened because we interpreted angle as unsigned when it should be
signed.
This adds support for loading the Global Lighting Angle, and using
that value in the legacy dropshadow effect.
We read the angle by using GUINT16_TO_BE because it's a signed int;
that also removes the need to check for 0xFF00.
Next we adjust the way we compute X and Y.
As pointed out by Dhiraj, it is possible to set width and
height values in the ICO header that will overflow a 32 bit
integer when loaded in. This patch adds checks using
g_size_check_mul () and g_try_new () to catch these
overflows and prevent them from crashing the plug-in.
In INTERACTIVE or WITH_LAST_VALS modes, the arguments were replaced by
the latest values, which is typically not acceptable for this specific
plug-in. Even in interactive mode, we still want file descriptors to be
set explicitly, and used by the plug-in.
This fixes such error I had on terminal:
> (busy-dialog:193133): GLib-WARNING **: 20:34:43.692: ../glib/giounix.c:414Error while getting flags for FD: Bad file descriptor (9)
And the worst part was that it sometimes prevented the busy dialog from
quitting (though sometimes it still exited fine despite the wrong file
descriptors 🤷).
Resolves#15632
Since our code expects WEBP time to be measured in
ASCII "ms", translating it causes the time between
frames to be ignored. This patch reuses the string from
the GIF loading plug-in so that we always add milliseconds
as "MS", per Daniel Plakhotich.
...lossless WEBP export
Resolves#15625
Per Daniel Plakhotich, we should use
WebPConfigLosslessPreset () when saving
lossless WEBP, so that the lossy quality settings
defined by the user don't override the lossless
values and unintentionally change the exported
file.
psd-image-res-load.c:1614:33: warning: variable 'init_fill' is
uninitialized when passed as a const pointer argument here
Although where it is used it is initialized in the function call,
let's fix it to get rid of the warning.
We were already considering the plugins under /common but
not the plug-ins that have their own subdirectories. So,
plugin_executables did not match custom_plugin_targets and
the build started to fail on macOS where install_name_tool
neeeds to process the plugins setting the right LC_RPATH.
Resolves#15554
This patch adds a check for if our pointer arithmetic
exceeds the memory allocated for the dest array. If so,
we throw an error rather than access memory outside
the bounds.
Resolves#15555
This patch adds some guards for ico_read_int8 (),
which was used for loading palettes and maps
without verifying that it returned the same number
of bytes as what it tried to read in.
When we fail to read enough bytes when reading uncompressed psp
channels, return with an error.
The error message was copied from the PSD reader so this should not
be affected by the string freeze.
We were not checking whether channel types were valid for grayscale
images. Using a blue color channel caused an invalid computation of
the offset which could cause us to access an invalid memory location.
Now we separate RGB from non-RGB images when checking which channels
are valid, and if not return with an error.
This commit enables GimpBrowser to emit the "stop-search" signal,
originally emitted only by the internal GtkSearchEntry.
It also connects this signal to all widgets embedding a GimpBrowser,
so they can intercept it and close themselves.
This restores the behaviour that existed before the GtkSearchEntry update
Without setting either the scales or the frame to expand the maximum
width the scales will assume is their natural one. Expanding them
prevents the two columns of widgets to appear "squished".
Fixes#15388.
The code was mistakenly calling gimp_ui_init to init gegl,
and then gtk_init was aborting in headless gimp-console.
Now require GimpPlugin class to init gegl/babl.
See next commit.
Call gimp_ui_init only when run mode INTERACTIVE.
Default values for width, height and offsets for ps export are
based on the size of an A4 paper in millimeters, so set the
unit default to millimeters as well.
This patch adds support for loading and
applying active legacy Outer Glow
layer styles in PSD images. It uses
gegl:dropshadow with certain preset values
to replicate the Photoshop filter.
Resolves#15286
Adds a check to the memory allocation
in pnm_load_raw () with g_size_checked_mul ()
to see if the size would go out of bounds.
If so, we don't try to allocate and load the
image.
Resolves#15292
The IFF specification states that EHB format images
have exactly 32 colors in their palette. However, it
is possible for images in the wild to place an incorrect
palette size. This patch checks for this, and either limits
the palette size or breaks accordingly.
- Though GimpDrawableChooser itself is deprecated, make it call the
new items popup API, which will work just as well.
- gimp_procedure_dialog_get_widget() will now return a GimpItemChooser
widget by default. I did hesitate if for API behavior stability, it
should not still return a GimpDrawableChooser, but considered that if
someone set G_TYPE_NONE, they want our "best choice" and are not
considering tweaking it. If someone wants to make sure this function
always returns a specific widget type, they should specify said type.
So I also added a note in the function docs related to this
assumption.
- Van Gogh plug-in must now use the GimpItemChooser API to set the item
to show. Also I am specifying the widget type, even though it is now
the new default, because of the previous point. Since we tweak further
the widget with its API, let's specify so that any further defaults
update doesn't break this code.
- Adding some pragma to ignore warnings on the few pieces of code where
we have to call deprecated functions (because inside other deprecated
functions themselves).
- gui_pdb_dialog_*() API should just always create GimpItemSelect
dialogs now. Also I ref rather than peek the class, because even if
the class has not been instanciated yet (a case I ran into), we still
want to obtain the class structure.
Resolves#15324
GimpSpinScale allows you to raise the value past the defined
limit, which can cause crashes when doing this for Raw Data
(since the upper bounds represent the maximum size of the
file).
For the 3.2 RC1 release, we'll convert back to GimpScaleEntry
and review before the final 3.2 release.
Even when choosing JPEG, we don't want a layer with transparency to be
stored as JPEG, because it will completely break the render (adding a
background color). So we need to make the JPEG option a "when possible"
one.
If anyone has comments on wording, please tell them!
Resolves#15285
Per the report, it's possible to exceed the size of the pixel buffer
with a high precision_scaled value, as we size it to the width * bpp.
This patch includes precision_scaled in the allocation calculation.
It also adds a g_size_checked_mul () check to ensure there's no
overflow, and moves the pixel and buffer memory freeing to occur
in the out section so that it always runs even on failure.
Resolves#15253
The R, G, B, A, and Y channels in an OpenEXR can be
stored as upper or lowercase. Our code always assumed
uppercase, and thus was not able to load valid OpenEXR
images that used lowercase channel names.
This patch adds a check for those variants.
I incorrectly read the GMainLoop documentation and thought that calling
g_main_loop_new with NULL as the first parameter will return the
"default GMainLoop". This is wrong and it resulted in the original
GMainLoop to never stop and therefore for the plug-in to never stop.
This also adds a call to unref for the GMainLoop.
The previous commit was not taking into account usages of
gimp_cairo_surface_create_buffer(), other than the text layer rendering
usage, as it was focused on fixing #14970.
In particular, in other pieces of code, we were using a temporary
GeglBuffer as a way to edit the original Cairo surface but the syncing
back was not happening anymore. So previous commit was breaking all
thumbnails of layers or images, as well as PDF export for all raster
layers.
After some thought, I decided to implement a new function
gimp_cairo_surface_get_buffer() which would do what
gimp_cairo_surface_create_buffer() was doing, but adding a boolean flag
to declare whether or not we were expecting to sync back into the Cairo
surface's data. After all, when we don't need to sync back, better avoid
the useless work of copying possibly huge data.
I also added back the possibility of returning a linear-memory backed
buffer, after some discussion with pippin. Because for very small
surfaces, and if we are indeed looking to sync back into the source
Cairo surface, the advantages of using a linear buffer may still be
worth it, even though it's not true for the general case (where tiled
buffers will be much more efficient). I used 4096 (64^2 because our
current tile dimensions are 64 right now in GIMP), though this number is
kinda random and doesn't matter too much (it doesn't have to be the
square of the tile's width or height). I don't put any info about this
in the new function's documentation because developers should not have
any expectations on the type of buffer they get (only whether or not it
will sync back to the source).
As a consequence of all this, gimp_cairo_surface_create_buffer() has
been deprecated as of GIMP 3.2, though it will still work the same. The
new function will be recommended as a replacement.
Resolves#15221
Unlike most of our plug-ins, Animation Playback
and ImageMap use GtkWindows so they're
not wired to close when the user presses
Escape.
To standardize this with other plug-ins,
this patch adds an entry for Escape in the
existing ImageMap key-press-event function
and adds this functions to Animation Playback.
This patch also fixes a crash in Animation Playback
that occurs if you use the arrow keys to
move the frame slider to the left when
you're at 0, due to it trying to pass an index
of -1 to the frame array.
Since GimpProcedureDialog automatically adds labels
to GimpChoice parameters when they're displayed in the
GUI, we don't need to add "Red", "Green", or "Blue" labels
to the frames that contain the radio buttons like we did in
2.10.
Closes#15226
When you previously exported a dds with the pre-existing mipmaps,
that will be the option selected in the export dialog the next time.
If, however, that next time there were an incorrect number of mipmaps
available, the option was grayed out, but selected. Exporting then
caused a crash due to less mipmap layers being available than expected.
When writing the dds settings we need to update that setting in our
config object, so that's what we add here. Also remove updating the
local variable since that will not be used anymore in this function.
When interacting with a layer/channel
widget in a plug-in GUI, a temporary
procedure is spawned. Script-fu plug-ins
run a check for translation whenever a new
procedure is run, but there's none available
for "temp-procedure-number-?" which is
spawned by the layer/channel pop-up.
This causes a crash because
script_fu_script_get_i18n () assumes the
script object it receives is always valid.
This patch adds a g_return_if_fail () call
to script_fu_script_get_i18n () to prevent
future crashes, and makes sure the script
object is not NULL after
script_fu_find_script () is called in
script_fu_get_i18n_for_proc () to prevent
the initial call for temporary procedures.
When gimp_file_save() fails, it does not necessarily mean that there was
a plug-in error. It can just be a CANCEL status.
In particular, when we were canceling the inner-format export dialog,
GIMP was outputting an error popup saying "cancelled" as failure error
message for the file-compressor plug-in. Now it will just return with no
error, as any other cancellation.
This issue was raised by Anders in #15152 and it was a mean one, because
it really looked like file-ani-export was crashing inside
_gimp_procedure_config_end_export() (so after its main run function),
but somehow only when being called from another plug-in (in particular
here, from the file-compressor plug-in). So it looked like a bug
somewhere in libgimp.
It turned out to be a "simple" memory corruption which was not
immediately showing its consequences.
This string is a bit tricky to find.
Go to "Menu > Filters > Web > Image Map."
This filter opens a dialog with a menu.
Go to "Menu > Tools > Use GIMP Guides..."
You can see that the command entry in the filter's menu is
"Use GIMP Guides," but it changes to
"Use Gimp Guides" in the dialog box title.
This patch fixes it.
We could have tweaked further the code to guess what is a meta file
procedure or not (what we have done until now) but I decided to be more
explicit and added gimp_file_procedure_[gs]et_meta() functions to
libgimp to tag a specific import/export procedure to implement a meta
format.
gimp_file_procedure_set_extensions() would still be used to list well
known formats using this meta format, for instance "hgt.zip" or
"xcf.xz,xcfxz" but the meta extension (simply "zip" or "xz"
respectively) would be used as such. No more "guessing" using the list
of extensions and assuming that at least one of them would have a dot
within.
It was broken in 2 ways:
- The parasite name was wrong, first because it used the old -save name
instead of the new -export name, but also because the prefix was
wrong. Since it is hard to automatize correctly having the correct
name (if this changes again), I left a quite exhaustive comment for
future people to easily retrieve where it is used.
- The format for the compression argument was wrong (it is now a
GimpChoice arg, which is serialized as a string).
Resolves#15113
There is code in the Gradient Flare plug-in to prevent deleting
gradients when there is only one left. However, the flare count
was not being properly updated. Due to a stray unbounded IF
statement, "if (tmp->next == NULL)", the num_gflares variable
was only decremented if you deleted from the bottom of the list.
As a result, you could delete all the flares and cause the plug-in
to crash when it tried to render a non-existent flare.
This patch removes the stray IF statement and adds additional checks
to make sure dlg->gflare exists before trying to get a pointer from it.
Resolves#14752
Our previous logic only worked for single-page PDFs.
If a multi-page PDF was exported, only the first layer
would have the background color set - the rest would
always be transparent regardless of user choice.
This patch moves the "fill background" logic deeper into
the layer drawing code, so that it is considered for each
layer rather than once at the beginning. It is also adjusted
for different situations, such as when the user wants group
layers to be combined.
- Some useless space cleanups.
- Properly free a string.
- Localize procedure documentation strings, except the help text for the
load procedure as it focuses on rendering to raster, which is true
now, but soon should not be! Let's not give useless work to
translators if we soon plan to change this. Also I don't think that
naming the library we use has much interest in a creator-facing
string.
- Fix export documentation strings (we don't export only vector
layers!).
There were 3 bugs which were kinda countering each other and
participating to some confusion regarding actual layer types to export.
First the previous commit as we were looking whether a layer had been
rasterized to determine the object type on libgimp side. Secondly this
commit as the plug-in was using the previously wrong procedures. Lastly
with the upcoming commit, when we were duplicating an image, we were
disregarding any rasterization.
