...in non-interactive cases.
gimp_export_image () handles various
tasks like rasterizing NDE filters. It only
runs in interactive cases however, so if the
users calls gimp-file-save the filters are
not exported.
Since Jehan removed the hidden dialogue
in 0dc9ff7c, we can now safely call
gimp_export_image () in all cases to make
image export more consistent. This step is
also preparation for setting up the new
API with GimpExportOptions.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
Resolves#10932
Since GIMP distinguishes between saving
XCF and exporting image like PNG,
we should change the PDB to show
export rather than save in the function
calls.
We compute the size of the mipmapped layers wrong. We assume that
width, height are always exactly a power of 2, which is the normal case
for dds images. See issue #11256.
Since other sizes are possible, we adjust this by computing the width
times height times bytes per pixel of the current mimmap level.
Comprehensive rewrite of the DDS import routine, in the interest of
easier maintainability and readability. Adds formats.c/h, containing
tables and functions related to reading and parsing uncompressed files.
Importer now supports nearly all non-video uncompressed formats.
Includes a variety of minor-to-moderate fixes made along the way
which could not be pulled out into separate commits due to dependence
on other aspects of the rewrite.
Per the official format specification and hardware implementation,
BC1 cutout pixels are always black with 0 alpha, whereas previous
versions of the plugin interpreted them as white. Commit f97e718e
partially fixed this, but made the behavior an import option that
also ignored the alpha component. This commit reverts the addition
of this option in favor of consistently following the spec.
The export properties "save-type" and "mipmaps" were left as ints
in Commit 427130be due to uncertainty on whether options could be
conditionally disabled on GimpChoice properties. From testing it
this functionality appears to work fine and is used in other plugins.
Now all combo props are GimpChoices and fully configurable from dds.c
Moves most of the code relating to YCoCg and Alpha Exponent into
misc.c/h, in the interest of making the rest of the codebase cleaner.
Removes the decode option from the import menu, as encoded files are
always decoded now (there used to be a menu button for doing this
after import, but with it gone there's no reason ever to not decode).
Finally, the remaining functions in color.c were only ever called once,
so these were extracted and inlined, and the empty file deleted.
Partial refactor of parts of ddsread to better handle DX10+ files.
Though not included here, this is necessary to import formats that
have no DX9 equivalent, namely BC6H and BC7, as the current handling
simply downgrades DX10 files and imports them like DX9 ones.
Extensive formatting and cleanup in the read-write files, and addition
of some comments where they seemed appropriate. Renamed a couple of
single-letter variables to be more descriptive.
Also removed an unnecessary global variable in ddswrite.c, and made
the "config" variable in ddsread a GimpProcedureConfig type, as was
previously done for ddswrite.
Fixes two major issues with mipmap generation, namely sRGB transforms
being applied both backwards and in 8-bit precision, causing severe
color degradation. sRGB transforms are now handled correctly and all
mipmap generation is done at 32-bit floating-point precision.
A new cubic filter has also been added (Catmull-Rom) which rounds-out
the existing lineup of cubic filters.
Also includes extensive code cleanup (sorry I couldn't separate this)
to mipmap.c/h and color.c/h
This adds an import option for DDS DXT1/BC1 images to always use
transparency. This is the default behavior, since this was what always
happened until now and it seems that DDPF_ALPHAPIXELS is very rarely
set for these type of images.
However, as the mentioned issues explains, advanced compression
algorithms can use this transparency data instead to mean a black
pixel. There is however, no certain way to determine this.
For that reason, we add an option here, that, if disabled, will
interpret fully transparent values as a black pixel.
Some games apparently need dds images to be vertically flipped.
We already have an option to flip dds images on export, so it makes
sense to also allow flipping on import.
In addition to the requested DXGI variants we also load the older
D3DF versions, including handling of the signed versions.
We also set signed when the pixelformat flag DDPF_BUMPDUDV (added in
the previous commit) is set.
This adds support for loading RGBA DDS images with 16- and 32-bit per
channel. Loading is supported for 16-bit half float, 32-bit float,
16 and 32-bit unsigned and signed int.
This supports both the DX10 formats and the D3D FOURCC versions.
16- and 32-bit per channel images with less than 4 channels are not
yet supported.
Certain dds images can have non-zero unexpected pitch_or_linsize values.
Until now we were only computing this ourselves in case it was zero.
Let's just always compute it and print an error to the terminal if it
differs from the value in the file.
A sample can be found in Galactic Civilizations 3: Bokeh_Hex.dds.
This change also allows us to safely load the poc in security issue
ZDI-CAN-22093 as that issue was apparently only caused by an invalid
value of pitch_or_linsize.
Optimize dds loading a bit by moving code that doesn't change outside
the loop:
1. The number of bits to be shifted when the source isn't exactly 8 or
16 bits depends on bytes per sample and isn't changing inside the loop.
2. Use rowstride variable to compute width * d->bpp once.
3. The check for rowstride > hdr->pitch_or_linsize doesn't change
inside the loop so move it out.
Inside the loop we only check the DDSD_PITCH flag once and move both
the size check and the fread check inside it.
There were 2 issues here:
1. When more than 8 bits per sample are used, a previous commit changed
it so that we would be using 16-bit integer mode instead of 8-bit.
However, the actual code for this specific format was not updated to
reflect that.
We fix this by computing 16-bits per channel values and upshifting the
10 and 2-bit samples to 16 bit per channel.
2. The computation of masks was incorrect. It computed each channel
mask separately, based on whether it was <= 8 or not.
However, if any channel needs more than 8 bits, all masks should be
computed 16 bits since we will then 16-bit integer mode.
We fix this by checking all channel bits together, and if any is higher
than 8, but not more than 16, we use 16-bit masks.
I also took this opportunity to add support for 32-bit masks if we
ever need those.
@Wormnest noted remaining regressions after 8faad92e.
The second fread() only runs if the DDSD_PITCH flag is set,
so the error handling check should also be conditional.
Additionally, the ZDI-CAN-22093 exploit no longer runs but
still could cause a plug-in crash. This patch adds an additional
check to ensure the buffer size was within bounds.
@Wormnest pointed out that compressed files are likely smaller than
width * height * bps, so our check to prevent ZDI-CAN-22093
also caught valid files.
The size check is removed from load_image () and moved to load_layer ()
before the two fread() functions, as we know exactly how much we'll
try to read at that point.
Note that "save-type" and "mipmaps" were left as ints rather than GimpChoice,
as some options are conditionally disabled and I don't know if that
is available in GimpChoice just yet.
A DDS loading bug related to 6ad54ca3 was also resolved.
The correct header value to check for the pixel size was not "depth" but "bpp".
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
… working with a GimpProcedureConfig.
These are the easiest ones to port as most of the work was already done (mostly
just some now useless calls to remove).
Resolves#10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
We have some examples of DDS images that have two 16-bit channels that
we could not load.
This commit adds checks to see if we need 16-bit channels, and conversion
of the input to a correct 16-bit red, green, blue or alpha channel.
Alx Sa