Users have noted that legacy layer modes have better compatibility
when exporting PSDs and reopening them in Photoshop.
This patch adds a notice with that information to the PSD export GUI.
- Use a pre-defined MAXDATABLOCKSIZE for all the buffers filled with
GetDataBlock that is known to be large enough.
- When reading comments ensure that it always ends with a NULL.
- Ensure that the right/bottom frame dimensions are also within range.
Inspired by issue #9195 I went over how we handled error messages when
loading GIF images.
- I replaced some cases with g_set_error and added an error parameter to
ReadImage.
- Introduced function read_error that uses g_set_error when image == NULL,
or else g_message.
- Enabled translations for the messages.
- Synchronized the error messages used to reduce the amount of work for
translators.
- Changed the error code returned internally in a few places, to be better
able to distinguish between encountering and end_code (-2) and possible
corruption errors (-1).
- Moved allocating dest down to not need freeing it in case of error.
- Allow to show partial results in case of errors.
The IART and INAM metadata fields were stored in gchar arrays,
which have a limit of G_MAXSHORT indexes.
However, you can have strings larger than that in the format.
To prevent overflows, they were changed to gchar*. f_read ()'s result
is also checked, and an error is set if it returns 0.
The frame count variable is also now reset per icon block to prevent
overflow as well.
This ports the main dialogue to use GimpProcedureConfig.
It also adds the GUI-only options to the procedure itself, so that you
can call them via scripts.
Additionally, the layer warning was fixed and
mnemonics were added to the
property titles.
@Wormnest notified me of issues with CMYK profiles overwriting existing
ones, and potentially access a dereferenced profile.
This patch adds an additional condition check, and clears out the
profile in addition to dereferencing it.
This adds "https://" as a valid website prefix in the ImageMap URL edit
field, in addition to http://.
It also restores the prefix change that 2.10 had when you switched URL
types. It also fixes code formatting in affected areas.
Adds a new PSDSupport struct to keep track of what unsupported features
a PSD contains.
It is then used to conditionally display a compatibility notice
via a GUI.
GIMP expects CSS palettes to end with a ";" when importing. However,
GIMP exports CSS lines without ";". This means GIMP can't reopen its
own exported CSS palettes.
The ";" was removed from the regex since CSS2 does not require
the last line to end with a ";". However, CSS3 and above
require ending all lines with a ";", so it is added to the
export script.
When porting IFS-Compose and GFig to GAction, I originally created
all icons as GtkToolButtons. However, the toggle buttons no longer
appeared "pressed in" when selected.
This is fixed by creating those as GtkToggleToolButtons instead.
A lingering UIManager object was removed from IFS Compose as well.
Additionally, the ImageMap-specific icons weren't showing up due to the
filenames not matching the references strings ("imap-polygon" but
the filename was "imagemap-polygon.png"). This patch fixes that by
renaming the strings to match file name.
Partial code style fixes were made as well; a lot more are needed.
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.
- 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.
This code is taken from Massimo's comment in #1786 and MR !834. It doesn't fix
a crash as this was already handled in !404, yet the missing prompt after
hitting "clear" was clearly not consistent with how one expect a clear feature
to work.
At least now, we've got a prompt back immediately after clearing.
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.
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.
Exports the following PAM formats:
GRAYSCALE, GRAYSCALE_ALPHA, RGB, RGB_ALPHA.
As with import, the main difference is the header and transparency.
Raw PPM export code is reused for the actual data.
PAM files are essentially PPM files with a different header format and
alpha/16 bit support.
Jörg Walter's 2.2 code was updated and implemented to read the revised
header format. The existing PPM loading code works with PAM files.
Largely inspired by commit dddb23c6. This also gave me a good overview of the
various missing features in GAction (compared to GtkAction) and how we'll have
to implement this in GIMP core. I now have a very clear path of what remains to
be done.
It relied on the now non-existing max-rgb plug-in, which was removed in commit
dd89f4a3d5. After some thoughts and discussions, the Predator script is fun, but
clearly not a mandatorily "needed" one here, which is why — instead of
re-integrating max-rgb —, I have decided to also remove Predator.
Both these script/plug-in are not totally dead. They were moved to the
gimp-data-extras repository and even ported to GIMP 3.0 API. They can be an
interesting use case for a fun extension to be installable through our future
extension platform. To be continued.
On Windows fopen () is limited to the current codepage,
GLib's g_fopen () instead accepts full UTF-8 by calling
_wfopen () internally (or a similar wide-char CRT routine).
This plug-in has a partial GUI (a FileChooser dialog is launched).
However, you could only save the active gradient rather than choosing
any of them like the 2.10 version of this plug-in.
This patch ports the original UI so you can choose both the gradient
and file in interactive mode.
It's a test plug-in which doesn't actually need an image to work, so it's
annoying that it currently requires one (making testing more cumbersome).
Also cleaning up a bit the coding style.
Also make the start checks a bit more robust to broken core code by
double-checking that the palette is valid from the start, even though getting an
invalid palette should normally not happen anymore (at least I fixed one such
case with a palette with a NULL id in my previous commit; but it looks like our
core code is not perfectly robust and we should push the code to extensive
testing).
Note that the generated widget is currently ugly (no label and terrible UX), but
this is meant to improve soon.
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
Adds import and export support for clipping paths in PSD files.
On import, path name and flatness value are saved in parasites.
Prior settings are loaded in the GUI on export.
Add a new type 'byte' to be able to handle binary data while still
retaining the utf8 char and string behavior.
Internally the file and string port and character handling have
been reworked to use the new byte-centric functions.
Also adds a new test script (test9) that tests byte, char and
utf8 string handling.
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.
This adds a check to make sure icon is valid when displaying
the icons in order, to prevent duplicates showing there and in the
invalid list at the bottom
There are so many paste options and I feel that the "Paste into Selection*"
actions are advanved enough that they can go into submenus. So I move them into
"Paste as". The other reason is that I'm going to add 2 more options!
I hesitated to rename the "Paste as" submenu but we couldn't find a good naming
(except just "Paste" but it's redundant with the default action and "Paste…" but
this usually implies a dialog, not a submenu).
Last but not least, I renamed the various paste actions to contain the word
"Paste" in it. E.g. s/New Image/Paste as New Image/. The old naming made sense
when action labels were only displayed in menus. But nowadays they can be shown
in other more independant context, such as the action search (and just
displaying "New Image" in there is very misleading).
- Use g_malloc* functions instead of malloc, so we don't continue on
failed allocations unless we test for NULL.
- Make sure we don't iterate past the known number of control points (ncps).
- Safely allocate, initialize and free points. Since points seems to be
used uninitialized, we use g_malloc0 to set everything to 0.
Thanks to a report by Stefan Cornelius, we became aware that the flame
plug-in does no checking for correct input when loading a pre-saved
settings file.
I reworked the parser to read one or more values based on the type of
token, making sure we also don't read past the end of our token buffer.
All int values have a min and max value set. If any unexpected input is
encountered, we will give a warning.
The flame plug-in can read stored settings from a file. The expected
input is that a ; signifies the end of input.
However, with user input we cannot depend on this to be true, so we need
to make sure that we do not read past the end of our input buffer.
To do so, we add a length check.
We were using the plug-in name with underscores, which is incorrect.
Since nobody ever complained about this, this doesn't seem to be used
very often.
We will use the const that defines the plug-in name instead.
Adds a toggle to let users load TIFF pages with FILETYPE_REDUCEDIMAGE
tags. The specs do not state that these are always thumbnails, and they
may have other uses. We assume that if only one page with this metadata
exists then it is a thumbnail; otherwise, the toggle option is
enabled on load.
Fixes:
> free(): double free detected in tcache 2
The file is closed also after resource_load() runs. Anyway it's better to free
resource on the same level they were created, so I remove the fclose inside the
function.
Just add a no-op flush() as I think it's actually unneeded in the context of a
GtkTextView GUI. At least it doesn't cause issues with copy-pasted code or when
using external libraries using the sys.stdout.flush() interface.
- 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…).
.ani files require metadata fields to be an even length. If the data
length is odd, an extra 0x00 is added for padding.
This patch updates the export and import code to comply with this
requirement.
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.
Adds an option to export as CMYK (mutually exclusive with the existing
Duotone export option). Header information (mode and number of channels)
are set, and the data itself is converted via Babl.
Layer channels are also hardcoded to 4, since GIMP currently doesn't
support CMYK channels.
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
GIMP tried to open webp files as ani (animated cursor) files. The reason
for this is that for ani we had set the file magic as the first 4 bytes
should be RIFF.
However, RIFF is a container format, used by many different file formats,
among which is also webp.
This means that checking for RIFF is not specific enough.
Based on the info on http://fileformats.archiveteam.org/wiki/ANI
we will check the 4 bytes starting at offset 8 for ACON, which is
apparently the identifying part for animated icons.
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.
- Setting an exec_dir variable is an error. As meson docs says, if
relative, it is installed relatively to prefix anyway: "If this is a
relative path, it is assumed to be relative to the prefix."
On the other hand, it would make problems if someone tried to set an
absolute bindir.
Moreover it is a lot clearer now. When we want to install in the
binary directory unconditionally, then get_option('bindir') is the
meson way, hence the way to go.
- On the other hand, the `gimp-debug-tool` is installed either in bindir
for Windows or macOS and libexecdir for all other platforms, at least
that's how it's set in the autotools build. So let's keep both builds
consistent.
- Make a hopefully clearer description for enable-default-bin option.
Let's clarify this is just about creating unversionning links pointing
to versionned files.
- Adding an item in the "Optional Features" part of the summary listing
during meson configure, for better discovery.
For the ".exe" extension on Windows, I wished we had an $(EXEEXT)
equivalent on meson rather than trying to set it ourselves (are there
other platforms where we must set a different extension?). But I could
not find any.
and import as inches
When GIMP's display unit was mm, our PSD export converted the X and Y
resolution as if a conversion from mm to inch was needed.
However, PSD's resolution is always measured in pixels per inch, so a
conversion is never necessary.
Removing the conversion, resolves the issue.
created by Adobe Lightroom 5.1
Adobe products are known to write incorrect RichTIFFIPTC tags in TIFF
images.
Since libtiff correctly detects and handles this there is no real need
for end users to be warned. So instead of a warning we will only output
a message to stderr.
This is essentially the same check as done in gimp_image_set_resolution,
but doing it here means we can load the image instead of throwing an
error.
We still need to get replacement xres and yres values, because these are
used to compute layer_offset_x_pixel and layer_offset_y_pixel.
Image m2-d0f86ab189cbe900ec389ca6d7464713.tif from the imagetestsuite
is a fuzzed image with an invalid very high number for the channel count.
This causes GIMP to become unresponsive for a very long time. Possibly
trying to allocate memory for all channels or another cause related to
the high number of channels.
Let's go for a more "reasonable" limit of 99 channels like we also do
for Photoshop images and show a message when we find an image with more
channels.
When loading a TIFF image using a script/plug-in in non interactive mode,
we did not initialize the list of pages, causing a crash when trying to
access it.
So, always initialize this list when non interactive.
Due to a change in the format string in libtiff, warnings about unknown
fields were not filtered out anymore.
Adjust our filtering of warning messages so we catch this again since
end-users don't need to worry about this and we don't need the
possible extra issues.
Optionally includes the previously saved
Duotone color space data on PSD export.
New load dialogue alerts user if duotone data was imported.
New export dialogue appears if the image is still grayscale and
the parasite exists.
If selected, the mode is set to PSD_DUOTONE in the header and
the original duotone data is written in the color space section.
Add the info about max dimension of WebP with WEBP_MAX_DIMENSION macro.
There is also a test about (picture->width / 4 > INT_MAX / 4), resp.
height, but this should anyway never happen as the C spec says the
smaller range for int is [-32767, 32767], which is an order bigger than
the current WEBP_MAX_DIMENSION (16383).
So we are probably fine assuming all VP8_ENC_ERROR_BAD_DIMENSION errors
will happen because of WEBP_MAX_DIMENSION.
Just duplicate the blurb into the help string. I'll leave it to someone
else to write a dedicated, longer help text if needed.
Also fixing the call s/Gimp.init/GimpUi.init/.
According to the specs the extra mask (which they call real user supplied
layer mask) is used "when both a user mask and a vector mask are present".
I haven't seen an example that has the extra mask, so not sure which of
the masks would appear first.
For now assuming that the extra mask will be first. The advantage of
adding this here now, is that we won't try to add a mask channel as a
normal channel.
Apparently some layers in PSD files can have extra channels which we
did not account for when computing destination offsets, causing crashes.
So let's make sure we don't include the "extra" channels when computing
the offsets by introducing base_channels. We also move the alpha channel
in the spot of the first extra channel (even though it seems, based on
the one example we have, that the extra channel might be the same as
the alpha channel).
Commit a6aba929 deleted the old functions.
Misc drive-by fixes for gtk_adjustment step not < pages
Issue #8155 discusses alternative fixes, convenience functions for compatibility in ScriptFu.
There is one compat function defined already in ScriptFu, temporarily: gimp-image-get-active-drawable
which was written so that testing clothify-v3.scm could proceed.
Resolves#8382
Also v2 scripts infer and set sensitivity to drawables
Add two test plugins clothify-v3.scm and test-sphere-v3.scm.
Temporary, to be removed when 3.0 ships.
Some refactoring (extracting methods, moving functions to new files).
Some drive-by fixes to script-fu-arg.c revealed by using GimpProcedureDialog.
Fixing !646. The call to gimp_image_set_simulation_profile() was only
happening for merged PSD mode (either explicit call or when
special-cases such as no layers).
This is the right place to store the CMYK profile in all cases.
Removes gimp_color_transform_process_pixels () calls
when a CMYK profile is present, and uses babl_format_with_space ()
instead for all cases. Additionally, possible errors are now recorded
during the conversion process.
If attached, the image's CMYK profile is stored in GimpImage
afterwards.
As noted by @Ofnuts, histogram-export still expected to receive
a single layer from GIMP. The parameters have been updated to
reflect receiving multiple layers/drawables, and the active layer
is selected. The parameter was left in case multi-layer support
is added in the future.
CMYK profile is now stored in GimpImage on load
(rather than being discarded) and it's used for export rather than
the default simulation profile stored in Preferences
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.
Now that images can contain their simulation profile,
we can use gimp_image_set_simulation_profile() to retain
the CMYK profile when a TIFF image is loaded.
It will then be accessible in GIMP's Image menu.
Adds support for saving 8 and 16 BIT CMYK/A TIFF files using the
image's simulation profile. If no profile or a non-CMYK profile
is set for the simulation profile, naive conversion is used instead.
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.
Why: puts most methods for SFArg (a struct) in one place, for ease of maintenance.
Prepares to fix issue 8328. Prepares to make SF use GimpProcedureDialog.
Mostly moving code, with no intended change in functionality,
except fixed an property.nick for an arg is now what a script author provided,
instead of generated.
All internal to libscriptfu. No changes to the exported API or to i18n.
Lightly tested, since more substantive changes coming for issue 8328.
ScriptFu>Test>Sphere is the test case.
Why:
1) users can install .scm scripts to plug-ins dir
2) Crashing scripts do not crash extension-script-fu
Scripts (.scm files) have a shebang and are executable
and in a same-named subdir of plugin dir.
Interpreter/scripts create PDB procs of type PLUGIN unlike extension-script-fu
which creates PDB procs of type TEMPORARY, owned by extension-script-fu.
Unlike other interpreters, the interpreter is-a plugin outright,
not by virtue of the script subclassing GimpPlugin and using GI.
More details in /plug-ins/script-fu/interpreter/README
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.
Create new plugin file script-fu-server-plugin.c
with code extracted from script-fu.c, which is an omnibus plugin
implementing PDB proc extension-script-fu and other PDB procs.
Why:
1. extension-script-fu is smaller and doesn't doesn't link to socket libraries.
(GIMP always starts extension-script-fu and it stays running.)
2. packagers/admins can omit script-fu-server executable from an installation,
if they think letting users serve net ports is not secure.
3. crashing script-fu-server does not crash extension-script-fu,
which requires restart of GIMP
The changes are mostly a simple refactor, extracting code.
No functional change apparent to users.
Low risk of introduced bugs.
Extremely few users use script-fu-server anyway.
Added some logging.
While at it, use G_DECLARE_FINAL_TYPE
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.
Changes are mostly to the dir structures and build system for ScriptFu.
Some changes to the outer plugin source to call the library.
Why: so that other executables (future gimp-scheme-interpreter,
or a future separated script-fu-server) can exist in separate directories,
and share the library in memory (when built shared.)
Whether the library is built shared and installed on its own
(versus static and not installed)
is a compile time option (both automake LibTool and meson abstract it away)
The default is shared and installed, say as libgimp-scriptfu-3.0.so.
Installed alongside other shared libraries (e.g. wherever libgimp is installed)
to simplify packaging.
A preliminary refactoring which helps enable MR gimp!647
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.
We only set tiff_mode for images with bps < 8, but we also use it for
8 bps grayscale images to detect if MINISWHITE needs to be converted.
So, let's always set tiff_mode for PALETTE, MINISBLACK and MINISWHITE.
generated by matlabs blocproc function
Based on the suggested solution by Massimo, we should not compute the
remaining pixels per line but only at the end of the whole block, be it
tile or scanline.
I have not been able to find bw or palette examples that use load_separate
instead of load_contiguous, so that case is not tested. But, it also
doesn't make much sense to have planar when you have just one plane.
In a previous commit 1, 2 and 4-bit B/W images were converted to grayscale.
However, it seems that there is more of a use case for these images to be
handled as indexed, even though technically they can be considered
grayscale.
Also, the only way to export these images again in the same format, is to
have them as indexed.
So, let's change this back, so that these kind of images will be opened
as indexed. With a reminder that in the future we could add an option
at loading time where the user can choose whether they prefer it to be
loaded as indexed or grayscale.
We use grayscale mappings, that we moved in the previous commit, to
add a palette to these grayscale images.
In preparation of using some of them earlier, we move the variables
used for grayscale mapping of 1, 2 and 4-bit per pixel images to the
top of file-tiff-load.
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.
- Set the "gimp30-python" Gettext domain and bind it to the proper
locale directory as installed by GIMP.
- Localize various strings with gettext.
- Remove calls to self.set_translation_domain() in
do_query_procedures(). This is technically wrong right now but I am
going to get rid of the menu item localization for plug-ins done by
the core.
We were using parameter iter in metadata_dialog_add_tag and
metadata_dialog_add_translated_tag.
However, iter is only ever set inside metadata_dialog_add_tag by calling
gtk_list_store_append. So, there is no need to pass this parameter around.
For this reason, let's remove parameter iter from the above two functions
and replace with a local variable.
Also fixed quotient to only take two arguments. Applied minor
optimization in execution of quotient, remainder, and modulo.
From revision 122 of the TinyScheme repository in SourceForge.
Instead, make outer script-fu-server register callbacks with inner scheme-wrapper.
Why? the inner scheme-wrapper should not know about the outer script-fu-server.
The change will allow a future, smaller scriptfu shared library,
that does not contain networking code.
We want a scriptfu library shared by separate script-fu-server,
future gimp-scheme-interpreter (!647), and script-fu executables.
This change does not alter observable functioning of the script-fu-server.
Except that I also changing the logging by script-fu-server,
so that I could test the changes.
I put a test plan in the comments.
Removal of the snprintf define was also part of the UCRT Windows patch
in MINGW. Although it builds fine without this change, there is no need
anymore to redefine snprintf. In addition, I seem to remember that
_snprintf had a shortcoming.
So let's remove the Windows specific code, since it works fine without it.
The UCRT environment is a successor to the MINGW environment on Windows
with a more modern C runtime library.
Building under UCRT we get this error:
../../gimp/plug-ins/file-raw/file-darktable.c:420:7: error:
function '__p__environ' is initialized like a variable"
To fix this we use the relevant part of patch 6 from:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gimp
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.
Added GError parameters to all static file write functions, check for
failed writing and return an error if that is the case.
Additionally, at end of file make sure the last dummy byte is written to
make chunks an even size.
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.
- Changed all static read functions to have a GError parameter, use a
parameter for the value read, and return a gboolean that will be FALSE
when reading from file failed.
- Check the return values of all read functions and set GError when
needed.
- Added more error checking, like comparing real filesize with what the
header tells us, check for valid speed and number of frames.
- Added some gdebug statements for easier debugging.
- Don't assume that all FLI/FLC writers followed the specs and wrote an
even number of bytes per chunk.
- Skip "frames" that do not have the FRAME type (in most cases this is
a PREFIX chunk).
Improvements to the FLI loading and exporting plug-in:
- I added a GError parameter to all public read/write functions.
- All public functions now return a gboolean result to show if they
succeeded or failed. Before most functions were void. For the non void
returns (the two fli_write_color functions) I added a gboolean
parameter.
- Do cleanup if we fail to read a frame. If at least one frame was read
successfully, we will keep the incomplete image/animation.
- Change name of layer to include the delay in ms.
Why: MR !389 changed the signature of PDB procedures to return GStrv instead of (int, GimpStringArray)
This changes handling of results from a call to such a changed signature, in a Scheme script.
The symptom was a cryptic TinyScheme "Error: car: argument 1 must be : pair"
Most changed procedures are named like "-list".
I did a cursory grep to look for other instances.
Updated porting guide doc.
The unsigned long type in this plug-in is always used for reading/writing
32-bit unsigned integers, so let's change it to guin32 to not get
confused.
Changed unsigned short to gushort, unsigned char to guchar.
Why: in v3 the signature for gimp-edit-foo PDB procedures changed to support multilayer selection.
This finishes the task for ScriptFu scripts in the GIMP repo.
This is not a complete list, since some calls were changed incidentally by prior commits.
You can grep for "edit-copy" etc. in script-fu/scripts to find instances.
This also makes incidental changes, to script calls to plug-in-tile,
which now also has a changed signature to support multilayer.
The changes are simple code transformations.
The changes to gimp-edit-paste calls are more complex,
a mixed bag of a few lines transformed to more lines.
I did not try to understand the larger logic of the changed plugins.
I did not test the changed plugins functionally.
I used a harness to call each changed plugin with improvised parameters,
only checking that the test plugin did not throw runtime errors,
not checking that they produced correct images.
As noted in the issue, this might be undone if the original signatures
for gimp-edit-foo are restored as convenience functions.
Why: this commit fixes PATTERN using code that commit 708f3228 fixed for BRUSH.
Importance:
There doesn't seem to be any issues it resolves.
No code in the GIMP repo seems to call this procedure.
I don't know whether third party plug-ins rely on this procedure.
Anyway, fix it so a brute force test works.
This change is part of multilayer select feature of v3.
Only fixes ScriptFu plugins, not Python or C.
Only fixes calls to file load/save procedures and other plugins already multilayer capable.
Any future PDB procedures changed to have multilayer signature will require changes to all callers.
The new code is verbose: "drawable" => "1 (vector drawable)"
Issue 5919 proposes a change to the PDB that would make this less verbose:
"drawable" => (vector drawable)" (without the number of drawables)
Tested that changed procedures will interpret without syntax errors, on one path.
Did not test each changed procedure for functional correctness.
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.
To be able to use certain variables we use in our DDS loader earlier,
we move the computation of these variables up.
We also add checks to see if the mask needs to be for 8 or 16-bit, since
there are DDS images with 16 bits per sample.
This was a long standing issue where the image was not printed at the
position as selected in our print preview.
The problem being that we do not take into account the dpi of the print
context we are printing to, but instead always assumed 72.
This is the fix that was suggested by Massimo.
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).
Also changing "RGB->YUV" by using a real Unicode rightward arrow encoded
in UTF-8 since GTK functions (such as `gtk_widget_set_tooltip_text()`)
explicitly uses UTF-8 encoded strings as argument. This renders much
more nicely than an ASCII-made arrow.
As mentioned by Massimo in issue #6618, part of the problem there is an
integer overflow when using large size images when computing the offset
in pixels.
Let's fix our part of the problem by casting to guint64.
Besides that, also use casts to correctly compute progress for very
large images.
We already had import support through littleCMS. We now use fully
babl/GEGL which makes our code more straightforward and identical,
whichever the input format.
The export support is totally new. It comes with a checkbox to propose
selecting CMYK export and a label displaying the CMYK profile which will
be used.
Now this whole implementation has a few drawbacks so far, but it will be
a good first sample for future CMYK-related improvements to come:
* The export profile I am using is what we call the "simulation
profile" from the GimpColorConfig. This corresponds to the default
"Soft-proofing" profile as set in Preferences. In particular, this is
not the actual soft-proofing profile for this image which might have
been changed through the View menu because this information is
currently and unfortunately unavailable to plug-ins. It is not the
"Preferred CMYK Profile" either, as set in Preferences.
TODOS:
- We really need to straighten the soft-proof profile core concept by
storing it in the image and making it visible to plug-in.
- Another interesting improvement could be to create a
GimpColorProfile procedure argument which would be mapped to a color
profile chooser widget, allowing people to choose profiles in
plug-ins. For an export plug-in in particular, it could allow to
select a profile different from the soft-proof one at export time.
* When we export, if no profile is choosen, babl will use a naive
profile. It would be nice to store this naive profile into the JPEG if
the "Save color profile" option is checked (same as we store a generic
sRGB profile when no RGB profile is set).
* When we import, we just import the image as sRGB. Since CMYK gamuts
are not necessarily within sRGB (some part of the spectrum is usually
well within, but other well outside), other than the basic conversion
accuracy issue, we may lose colors. It would be much nicer to be able
to select an output RGB profile. Optionally if we could create a RGB
color space which is made to contain the whole input CMYK profile
color space, without explicit choice step, it would be nice too.
* I am using babl's "cmyk" format, not the expected "CMYK" format.
"cmyk" is meant to be an inverted CMYK where 0.0 is full ink coverage
and 1.0 none. Nevertheless when loading the resulting JPEG in other
software (editors or viewers alike), the normal CMYK would always
display inverted colors and the inverted cmyk would look fine.
Finally I found a docs from libjpeg-turbo library, explaining that
Photoshop was wrongly inverting CMYK color data while it should not.
This text dates back from 1994, looking at the commit date which
introduced this paragraph. In the 28 years since then, could this
color inversion have become the de-facto standard for JPEG because one
of the main editor would just output all its JPEG files this way?
See: dfc63d42ee/libjpeg.txt (L1425-L1438)
… plug-in code.
In particular, we should not hardcode this in core code anymore. The
behavior is otherwise exactly the same, except that we made the core
code generic as it should be.
The CLI options now know which procedures are batch procedures or not.
First it means that it won't just randomly try any procedure name one
may pass and will properly output an error if you pass a non-existing
interpreter procedure.
Secondly, there is no default interpreter anymore (unless only one
interpreter exists). If you don't set an interpreter procedure with
--batch-interpreter or if you pass a wrong one, it will output the list
of available batch procedure, thus helping you understanding how to use
the --batch option.
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.
Some coding style fixes, also one warning fix, and a lot of shuffling
around to reorganize the code. Basically removing the prototype listing
at the file start is a big error. This file is huge and without a
minimum of organization, it's a huge mess to understand what's what.
Basically a class file must always start by the class_init(), then the
init(), then the various object methods (constructed() or finalize() if
any, etc.), and possibly other parent classes' implementations. These
are the entry points, it's normal to start here (not from leaf
functions!).
Then we get the public functions which are other entry points (calls
from other parts of the code). And only after, private functions such as
signal or action callbacks, and utilities at the very end.
This requires a well organized prototype listing, which works as a menu,
and prevents the implementation order to depend on call order (this gets
us completely random order and imply usually that top functions are the
less important ones, such as utilities, just how it was before this
commit).
Anyway I'm not sure why I spent time on this because we deprecated this
plug-in, but if we still want to push nice updates (like MR !519), we
should at least do it well and clean. Also it's a good first example for
plug-in rewrite in modern no-GtkAction code.
The initial attempt of this commit was to remove the `GtkAction` usage,
but grew a bit wider than that. The following happened:
* The dialog became a proper GObject, rather than being a big chunk of
static variables that were hopefully initialized before you used them.
* The dialog now uses `GAction`s to implement actions, and converted
some signal handlers to actions as well.
* The plug-in run procedure now uses `GtkApplication`. This is one hand
necessary to be able to set accelerators for actions, but on the other
hand is more future-proof, as GTK4 removes `gtk_main()`
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)
Committer's (Jehan) note: with clang version 12.0.0 on macOS Big Sur,
it seems that warnings such as the following are outputted:
> plug-ins/file-psd/psd-load.c:447:32: warning: variable 'block_len' is uninitialized when used here [-Wuninitialized]
> block_len = GUINT32_FROM_BE (block_len);
> plug-ins/file-psd/psd-load.c:2312:34: note: initialize the variable 'comp_mode' to silence this warning
> guint16 comp_mode;
Recently it was not possibly in master to open online help (F1).
This is also mentioned in issue #7915. However, on macOS there are likely
also other problems, which is why I'm hesitant to close that issue with
this fix.
(help.exe:57964): LibGimpBase-CRITICAL **: 15:24:38.792:
gimp_value_array_index: assertion 'index < value_array->n_values' failed
(help.exe:57964): GLib-GObject-CRITICAL **: 15:24:38.792: g_value_get_boxed:
assertion 'G_VALUE_HOLDS_BOXED (value)' failed
This was most likely caused by 8eb7f6df9e
Changing this to use args 0 and 1 instead of 1 and 2 fixes the problem.
As raised on social networks, the big label grows the horizontal size of
the dialog. Make the label wrappable and give it a smaller wanted size
(otherwise, just making it wrappable is not enough and the dialog is
still too big when first appearing, because of how GTK handles such
widgets :-/).
Actually I realized that using BigTIFF is not the only valid alternative
here. We can also try to use a better compression algorithm (or any if
"None" were selected) and try again to export as ClassicTIFF.
So don't check the option ourselves and don't set it insensitive. Let
one choose fully what they prefer to do.
… because we reached max TIFF size.
We detect the specific TIFF error (by string comparison so it's a bit
weak IMO yet it doesn't seem like libtiff provides anything better;
let's trust they don't change their error strings), then we reopen the
export dialog, pre-checking the BigTIFF checkbox newly created (and
making it insensitive). We still fail with error if an error happens the
second time (even for the same error).
Recent libtiff supports loading BigTiff automatically so we didn't have
anything to do there (as long as a recent libtiff was used). For
creating a BigTIFF though, we simply needed to add a "8" flag to
TIFFOpen/TIFFClientOpen when creating a new image (i.e. using "w8"
mode) as explained here in the "Implementation Strategy" section:
http://www.simplesystems.org/libtiff/BigTIFFProposal.html
What this commit does:
- Explicitly bump our libtiff requirement to version 4.0.0 or higher
(which is where BigTiff support appeared).
libtiff 4.0.0 was apparently released on 2011-12-22 and is available
on all current distributions, so it's probably not a problem.
- Switch to detect libtiff with a pkg-config test (added in libtiff
commit faf5f3eb before 4.0.0 release, so it's fine) instead of
function checks.
(Note: meson was already detecting for libtiff-4 with pkg-config,
which was obviously wrong since it should have mimicked autotools, but
well… then changes were minimal on meson)
- Add a new "bigtiff" boolean argument to the "file-tiff-save" PDB
procedure, FALSE by default. I set this as the first argument as I
figure that choosing the format you want is quite a major choice.
Unless I misunderstood something, since BigTIFF is really designed to
be an evolution of TIFF with a "minimum change strategy", i.e. mostly
using 64-bit instead of 32-bit offsets, everything which is possible
in TIFF will be in BigTIFF (and oppositely as well, except of course
having huge files) so there is no need to have 2 separate procedures.
- Adding this new argument to the GUI dialog as a checkbox.
- Tweak the load and export procedures' documentation strings to make
clear we support both TIFF and BigTIFF.
Note: interestingly there doesn't seem to be a separate mimetype for
BigTIFF so nothing to update on this side.
- Tweak the procedure labels too to mention BigTIFF. Since BigTIFF is
still a different format (though very closely resembling) from TIFF,
unlike some others which are just extensions embedded in a TIFF file
(like GeoTIFF we recently added), I figure it deserves to be
explicitly cited.
Since we increased our minimum version of gexiv2 to 0.12.3, several
functions used in the metadata-viewer plug-in have been deprecated.
Replace these functions with the "try_" versions, which include an
error parameter. If this returns non NULL then we print the error
message to the console.
The default for color properties (GimpRGB) is now to be editable. So
let's remove the formerly specific call for this.
Also fixing a clashing mnemonics ('c' both for '_Color' and '_Cancel').
Let's sync with the proposal in !571 after discussing with Jacob. The
shorter naming is fine and the '-info' suffix feels a bit redundant
anyway. Also since this arg never even existed in GIMP 2.10 (until !571
which is soon to be merged), there is really not even a historical
reason.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists 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 string 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
MR !565 was only a partial implementation as it was assuming all cursors
had the same hot spot coordinates in the file, which is false more often
than not (since usually it's several sizes for the same image, hence
coordinates move). I should have realized this before merging.
With this new commit, we actually loads the hot spot coordinates per
cursor, stores them as per-layer parasites, then exports with per-cursor
coordinates.
Also it makes the procedure API use int32 array (should be int16 but we
removed the support, now I think it may have been a mistake) which shows
the ugliness of our array support once again with additional size args
per array (even if it's the same size). Also I realize that our support
of arrays with config object is not good. This is also something we'll
have to look at.
- Fix return value in error case: s/GObject.Error/GLib.Error/ and anyway
in this form, the error should be a string. Using the easier form
procedure.new_return_values() instead.
- "file-png-load" uses a GFile now (like all load procedures).
This is the same issue as with IM000001.dcm mentioned in issue #313.
There are two problems: incorrect endian conversion for 16 bits per pixel,
and not handling photometric interpretation "MONOCHROME1", which means
minimum value is white instead of black.
The endian conversion was fixed as suggested in issue #313.
For "MONOCHROME1" we added a variable bw_inverted and we invert the pixel
value if that variable is true.
Exporting an image to TGA fails with a crash when it's an indexed image
with alpha channel. We were not taking into account that even though
the output is 1 byte per pixel, the input should allocate memory for
2 bytes per pixel (1 color index and 1 alpha channel).
There is no change for lossless images, where import precision
is directly related to bits_per_sample.
However, according JXL developers, for lossy images
(which generally use XYB color space), decoded data are not tightly
bound to bits_per_sample from header, import in 32bit
float precision can be used for better import quality
(libjxl works internally in 32bit float precision).
JPEG XL plug-in always imported all JXL images
in 32-bit float precision in the past.
Now it also supports direct import in 8-bit
and 16-bit integer precision too.
It was calling plug-in-gradmap with old single-layer API hence failing.
Also replacing all calls to (gimp-image-set-active-layer) and
(gimp-image-get-active-layer) in this file with
(gimp-image-set-selected-layers) and (gimp-image-get-selected-layers)
respectively.
Alx Sa