In file-xpm, use_x_api is only used when
GDK_WINDOWING_X11 is defined. However, it was
included as a general variable so it threw an unused variable
warning when compiled on other systems.
This patch moves the variable declaration inside the first
#ifdef GDK_WINDOWING_X11 block of the parse_colors ()
function.
We dropped 32bit Windows support in
GIMP 3.2.2, which also removed the
32bit-only TWAIN scanner plug-in.
This patch adds a new plug-in that uses
the 64bit compatible WIA API for scanning.
It should restore the support for scanning on
Windows.
...against IHDR bounds in APNG loader
The pixel buffer is allocated using base image dimensions from the IHDR
chunk, but row write offsets were computed using the per-frame dimensions
from the fcTL chunk with no bounds check. A crafted APNG file with
fcTL.width > IHDR.width or fcTL.height > IHDR.height would cause
out-of-bounds writes into the heap on every row after row 0.
Reject fcTL frames whose dimensions or offsets extend beyond the base
image dimensions before proceeding with decoding.
Now instead of just unexpectedly ending the plug-in process, let's
gracefully return with a GIMP_PDB_EXECUTION_ERROR and proper error
message, when any of the stream-writing function fails.
I am going to deprecate this function. We should stop just killing
plug-ins randomly when things are bugged. Instead we should still try
and return cleanly (with an error status and message).
And use the function in script-fu. While we want wrong resource names to
trigger WARNINGs in Script-Fu scripts and plug-ins (because these can be
considered as a bug), we don't want it to happen when the resource is
not loaded on purpose (mostly it means that we run GIMP with --no-data
or --no-fonts). This was happening in our own builds when running GIMP
through the in-build-gimp.py script and that was always very annoying.
Now in such a case, we will only output an INFO message on stderr (it's
still a good idea to warn about this, because if we imagined someone was
running a script non-interactively, which called one of these
procedures, they may have relied on the default value of some arguments.
Therefore they'd want to know about such a behavior change).
It is not a fix yet for #14681 but would provide nicer and earlier error
when a call to gimp_temp_file() fails, which may happen in some cases.
E.g. if the temp directory doesn't exist and we fail to create it.
As a test, if I delete /tmp/gimp/3.2/ and give root ownership to
/tmp/gimp/, now the error when opening our gimp-splash.xcf.xz is:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating directory /tmp/gimp/3.2: Permission denied
This is a further improvement, for the specific case which appeared on
issue #16160. Basically here for the specific case when we have
permission issues, or other similar issues where we fail to either load
the input image, or export to the temporary file, we would get more
explicit error messages. And this would also show in the stderr output
of the in-build-gimp.py script.
In particular, when reproducing #16160 permission issue, the build logs
now contain this error:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating temporary file '/tmp/gimp/3.2/gimp-temp-1719540.xcf': Permission denied
This should better help diagnose similar issues in the future.
Resolves#14583
If the user chooses to vectorize PDF layers with single colors,
get_layer_color () is run to use histograms to determine if they
are indeed a single color. gimp_drawable_histogram () is used to
get the RGB values as averages. This function returns values in the
0...255 range for 8-bit images and 0.0...1.0 range for all the
other precisions.
However, we did not properly normalize the values, resulting in
blown-out white layers when exporting 8-bit images. This patch
checks if the image is 8-bit and divides all values by 255.0f in
that case.
It also checks if the image is in linear precision or not, as
gegl_color_set_rgba () assumes the color values are linear. If not,
gegl_color_set_pixel () is used instead. Finally, the color mode
checks are made a bit more robust in preparation for future color
modes like CMYK.
Resolves#16151
The original implementation mixed up the variable that
needed to be used for boundary checks - it should be
"estimated_size" and not "flags". This patch fixes the issue
to prevent a buffer overflow.
Resolves#16150
Per Bronson Yen, it's possible to create a transparent chunk
that's larger than 256 index values. In that case, the trans[]
array will overflow since we initialize it to 256 indexes.
This patch adds a check to make sure the iterator used for the
transparency for loop does not exceed the array size even if
the chunk size does.
There are reports that clang-based compilers create
a TIM plug-in that crashes when exporting. This seems
related to the method used to convert RGB images to
indexed when choosing TIM textures with palettes on export.
This patch switches to using gimp-image-convert-indexed
instead, to prevent the format mismatch crash on initial export.
Previously, paths from Photoshop TIFF files were appended via
gimp_image_insert_path(..., -1), which caused the displayed order to be
reversed. This change preserves the original ordering while keeping the
'Working Path' as the last element.
When loading layer metadata from TIFF 'ImageSourceData' Tag, don't assume
'Layr' is the first 8BIM block. Iterate over 8BIM/MIB8 blocks, skip non
'Layr' blocks, and rewind 4 bytes before calling read_layer_block() so it
can read the length field as expected. Limit mask_layer_len to the
selected block (including padding).
Multichannel PSD images reuse their first channel as the
main grayscale "layer". Our PSD plug-in did not take this
into account, resulting in the channels being off-by-one and
mislabeled.
This patch prevents chn_a[0].data from being freed after
it is used to load the layer, and then resets the counts so that
it is reused as the first imported channel.
968cf06a only loaded the rectangle area that the
selection was contained in, rather than the actual
channel data. This patch extended the code to
also read in the PSP_CHANNEL_BLOCK data, add
it to the selection GeglBuffer, and then shift it over
into the correct location.
Resolves#16076
As reported by chamal, it is possible to craft a
Jeff's Image Format image with header values that
are larger than the file size. This can lead to buffer
overflows when loading the data. This patch adds
bounding checks based on the size of the stream.
Resolves#16075
As noted by chamal, it is possible to cause a buffer overflow
in a crafted SFW file. This patch adds bounds checks to prevent
this from occurring.
Resolves#16058
Per mzfr's observations, this patch adds more
safeguards to PVR import. Memory for data and pixels
is allocated and checked rather than using arrays.
Twiddled patterns are increased to 2048 and we
verify the dimensions are in that range before trying
to access. If users share an image that is larger than
that, we can increase this limit further.
Resolves#16056
Per mzfr, we should check if the cursor exceeds the
icon total size in icns_slurp () (per OSX icons) as we
do already in icns_decompress ().
Additionally, we were not deleting the temp_image created
to load each icon, and in fact we were making an unnecessary
blank temp_image before receiving the one from the PNG &
JPEG2000 procedures. This patch fixes both problems.
Per mzfr, we should dynamically allocate memory
for the PAA plug-in pixel data rather than rely on the image
being small enough for an array to store its information.
