Adds option to export JPEG XL images in CMYK/A format.
Key and Alpha data is saved in extra channels, and the
simulation profile is saved as well.
Per the specification developers, the format does not
support 'naive' CMYK conversion, so a profile is required
for export. The option will be disabled if not set.
Checks if file has an extra key channel for CMYK. If so, it is combined
with the image's CMY image to create a CMYK buffer for import.
Color profile is stored as image simulation profile.
If alpha channel is present, it is now loaded as well for CMKYA images.
- Don't forget to run gimp_ui_init() to get GIMP's styling in plug-ins.
- Process the "key-press-event" signal so that Escape key closes the window (as
it used to before the MR commit).
- Expand vertically the tree view, otherwise resizing the window leaves a lot of
ugly empty space, even though the tree view is still shown incomplete with a
scrollbar.
- Fix the Help button (which was doing nothing).
- Use full words for the "Refresh" and "Help" buttons, rather than icons. Text
is usually prefered for UI discoverability/understandability, unless there is
a space issue (i.e. too many icons for all of them to be words).
- Add a "OK" button too, and reorder the buttons similarly to how we usually
order them.
- Minor coding style fixes (alignments…).
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
Write both ICC and NCLX boxes for RGB AVIF to make sure that
all browsers render the AVIF images in same manner.
Use heif_init/heif_deinit in libheif 1.13.0+
Something I wanted to implement for a long time and today I finally took
the time after I had one more annoying case where I had to merge all
groups for exporting then undo for saving!
Now this won't be needed anymore as the plug-in will allow to export
only as pages any first-level layers (groups included, so you could
gather your page compositions in root layer groups). For me, it's the
only way I use this when making/editing PDFs with GIMP, but maybe some
people would still want GIMP to crawl into groups and subgroups and
export layers individually. That's why I make it an option, defaulting
at TRUE.
Note that I didn't port "file-pdf-save-multi" at this point, though I
did move to using GimpProcedureConfig instead of GimpValueArray
everywhere.
In any case, that's a lot of code removal and simplification already,
though some part of this plug-in is still a bit ugly.
We also get proper config storing between sessions now.
As for metadata, it unfortunately doesn't look like Exiv2 has PDF
support, so I didn't add metadata settings.
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
Due to a typo in the config property "default-delay", loading of that
option and the ones after it, failed.
Because of this, default-chunks had an invalid value, which made our
export fail. After correcting the typo the export succeeds.
libxml has a XML_PARSE_HUGE parsing option, which can be turned on with
the RSVG_HANDLE_FLAG_UNLIMITED option in librsvg.
We cannot just set this option by default because it is a security
hazard as a maliciously malformed SVG could use this to consume too much
memory.
Instead, let's just propose the option interactively when we fail to
create a rsvg handle. Unfortunately right now we can't single out this
specific error because librsvg actually returns an unrelated (false
positive created by the huge data) error. So we just propose the option
for any kind of handle creation failure.
Furthermore, the option is only available on interactive plug-in calls
so far. In particular, the PDB API doesn't have an option allowing a
script writer to run "file-svg-load" with the huge data option.
As for the thumbnail API, it is never meant to be used interactively and
not really as a common script function, so it won't have the huge data
option either.
The Makefile.am was apparently updated by hand in !662.
Also fixing plug-in label and doc localization, since this changed
recently and must now be localized directly on plug-in side.
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.
Instead of having a single "Planar RGB" format in the list, let's add
this as a generic parameter. Not only does it make the feature
symmetrical to "file-raw-save", but it also bring the ability to all
multi-channel formats. So now, we can load RGB, RGBA, GRAYA, whatever
the bit depth and the data type stored in planar configuration.
… "endianness".
The list of formats being a single list was actually interesting
UI-wise, in the case where you aren't sure of the data layout (but say
you know at least the dimensions), you can easily and quickly scroll
through the combo list (e.g. with keyboard arrows).
But when you knew your data, it was a pain to use. And as a general
rule, so many choices in a list is not the best interface.
I broke the option into 3 options, and in particular adding a
"data-type" which would tell what type of values are stored (integer,
signed or unsigned, or float) and an "endianness" to tell the byte
order. The idea behind is that these don't change the layout of
components and their size. It means that we can still do the
scrolling-randomly-through-formats trick in some fashion because we
might likely be able to detect shapes when we get at the right layout,
even though we are still set to use the wrong data type and/or the wrong
endianness.
… loading support as raw data.
Barely any new code (and actually a bit chunk of removed code) as we are
using generic code paths now.
"file-raw-load" procedure now supports all possible formats which can be
exported by the "file-raw-save" procedure (and more).
Only thing remaining now is looking how to simplify the GUI because this
overlong Pixel format combo box is quite a pain.
Since we can now export these, let's add import support.
I copied the function halfp2singles() from babl code (as-is, without
formatting according to our coding style on purpose as we might just
want to switch this again later on).
I add the Little and Big Endian variants, but not the signed one for
now, because I am unsure how common it is. We have signed grayscale
variants, but it might be specific use cases there.
While adding these new loading support, I factorize the code when
possible by making all full-bytes RGB/Grayscale code more generic and
using the same code paths. In particular, raw_load_gray_8_plus() is now
removed as raw_load_standard() will handle all full-bytes use cases
where the input and output formats have the same components in same
order.
Also RAW_RGB and RAW_RGBA are renamed to RAW_RGB_8BPP and RAW_RGBA_8BPP
respectively.
- rename raw_load_gray16() into raw_load_gray_8_plus() and make it
handle all full-byte grayscale data. Move 8-bit grayscale data to use
this function as well.
- As a consequence of the previous point, we can also easily support
32-bit grayscale images (little/big endian, signed/unsigned).
- Make preview image code more generic as well.
Also I improve a bit code from previous commit in raw_load_rgb565(). The
allocated and read code didn't need to be the size of the full line
stride. Just the tile rectangle width was enough.
Rather than allocating 2 huge data buffers of the whole image size (one
in RGB565 and one in RGB-u8), just iterate through the file only
creating one single small temporary data buffer for single input line in
tiles returned by the iterator. This will be much better,
memory-efficiency wise.
Should have paid more attention. I left 2 warnings in the file:
> plug-ins/common/file-raw-data.c:1949:22: warning: variable ‘procedure’ set but not used [-Wunused-but-set-variable]
> plug-ins/common/file-raw-data.c:1970:48: warning: ‘bpp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Even though the scale entries have maximum values based on the file
size, it's still too big for many formats (multi-byte ones) when
thinking in terms of pixels.
Moreover if growing the offset or any dimension, comes a point where the
other dimension needs to shrink. So let's compute max pixels and update
other values depending on this.
Note that it's still quite easy to crash the dialog with big dimensions,
triggering X Window System errors about unsufficient resources in
GimpPreviewArea code. This will have to be handled accordingly.
- Add various relevant arguments to "file-raw-load" PDB call: width,
height, offset, color-representation, palette-offset palette-type and
palette-file. This will make the procedure actually usable for
scripts.
- Use procedure config so that we get configuration storage as all other
ported plug-ins.
- Update the source to use passed-in config object with these new
arguments rather than global variables.
- The load dialog now uses the GimpProcedureDialog which means a lot
simpler and nicer to read/debug code (we don't need all the code for
argument syncing).
- "file-hgt-load" code now uses a HgtSampleSpacing enum, which makes
code nicer to read, with semantic constant names.
- Do not show the dialog anymore for HGT load when sample spacing
detection worked correctly. Indeed, offset and profile selection were
making sense for random raw data, not for HGT file which we know how
to process.
- Improve detection logic for sample spacing: in interactive mode, we
always try and detect and show the dialog when spacing detection
failed; in non-interactive mode, we only detect when "sample-spacing"
argument is explicitly set to HGT_SRTM_AUTO_DETECT.
- The argument "image-type" of "file-raw-save" PDB call is renamed to
"planar-configuration" to sync with the natural language label. Also
it now uses a separate RawPlanarConfiguration enum rather than using
specific values of the RawType enum (which made that the possible
values were 0 or 6, which was a weird API in GIMP 2.10).
The plug-in still cannot load all possibly exportable formats (after
commit 01e0675f67) and I'm still wondering about whether
"color-representation" argument in the load call should not be broken
down into several arguments (it has both advantages and disadvantages).
This will be handled in further commits. For this first step, I needed
to clean the load code.
Another part for the fix: now that it is possible to export any of the
color model and bit depth supported by GIMP core, we should make the
dialog settings clearer. In particular, don't just always show "RGB"
structure sample.
If an alpha channel is present, also show RGBA samples, and if it's a
grayscale image, show "Y" or "YA" samples. Actually when it's a
non-alpha grayscale, just make the option insensitive as planar and
contiguous will be the same thing.
Only port the export dialog so far. We'll see later for the load dialog.
This uses the new gimp_procedure_dialog_get_int_radio().
While doing this, I also better name "Image type" to "Planar
configuration", which is how DICOM standard and TIFF call the same
option. Within this settings, "Standard" is renamed "Contiguous" as a
more correct naming than a very vague "standard".
Similarly I rename "Palette type" to "Palette's configuration".
This is a first step to make RAW export clearer in the path of fixing
issue #7091.
I forgot this one, which simply can have its localization disabled. As I
understand, it's mostly for script writer so was never localized. Maybe
it could still be interesting to localize the procedure name and docs,
but for now let's leave it how it always was.
I guess I missed this one as I was not building it locally.
Fixes:
> In file included from ../plug-ins/common/file-jp2-load.c:86:
> ../plug-ins/common/file-jp2-load.c: In function ‘jp2_class_init’:
> ../libgimp/stdplugins-intl.h:42:22: error: ‘set_i18n’ undeclared (first use in this function)
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.
when Offset and Dimensions Bigger than File Size.
If we didn't read the exact amount of bytes, the whole image would be
filled with white.
Let's change this, so we read as much bytes as we can, and fill the rest
with white.
The animation playback now follows user preferences for checkboard
rendering.
Also fixing a small bug there, as the GIMP_CHECK_SIZE_SMALL_CHECKS was
the wrong type (it needed a check type, not a check size parameter).
Right now, the various Gimp*Preview classes have code initializing their
transparency colors correctly. Some plug-ins, such as tile-small are
directly using a GimpPreviewArea and need to be initialized directly by
the plug-in.
I also realized that several plug-ins (such as gradient-flare) are
rendering their own alpha checkboard, despite using a GimpPreviewArea
(maybe was it code from a time before this class had support for alpha
checkboard rendering?). So this would have to be improved later.
Small text tweaks done too:
- Some question marks removed to be more consistent in the tooltip
style.
- The "save-transparent" only applies to *completely* transparent pixels
(not partially transparent).
As suggested by jeremyd2019 and Biswa96 of MSYS2 project, defining the
MNG_USE_DLL macro would trigger libmng header code to fix the calling
convention. This way, even the old detection code now works with Windows
32-bit.
The reason why we still stick to this old detection code is that the
pkg-config is likely not everywhere (e.g. in Debian package libmng-dev,
there is no `.pc` file). So the pkg-config test is good but we still
definitely need to keep our fallback more old-school test for this
dependency.
See this comment in particular:
https://github.com/msys2/MINGW-packages/issues/11136#issuecomment-1084627263
Note: I am unsure yet how to apply the same trick on the autotools test
because AC_CHECK_LIB() would allow us to tweak the cflags to define a
macro, but we also need to include libmng.h header, otherwise the
calling convention tweak is not run. It doesn't look to be feasible with
the autoconf macro, or at least I haven't found how yet.
Our main issue is that GIMP does not accept indexed images with linear
backend. MR !460 was an attempt to fix this, but some weird pixel data
conversions were happening so the result was very wrong.
We could try to investigate this and add support for linear RGB palette
colors, but it's unclear how necessary it is (i.e. is there any indexed
image format for which we'd want this? PNG is not one such format as
will be explained below), especially that palette are u8 only right now
and linear RGB u8 is not the best idea anyway.
In cases reported in #6886 though, our code would say the input is
linear mostly because it had a 1.0 gAMA chunk (or we could have a case
with a linear profile too). But then we don't need to set such data as
being in linear RGB. Just set it as non-linear RGB (R'G'B') with the
associated linear profile and that's it.
Setting a linear backend to an imported PNG would only be useful if PNG
had some flag explicitly asking for this, bypassing any profile TRC. But
as far as I can see in its spec, there is no such thing.
The code can be 0, but not the domain. Let's use G_FILE_ERROR as all
these errors are about problematic file contents.
Fixing these warnings:
> g_error_new_valist: runtime check failed: (domain != 0)
Alx Sa