Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
...export dialogs
Remove the "Advanced" expander and have all options in plain sight.
Issue #701: Add a "Save color profile" toggle and always honor it.
by using gimp_image_get_effective_color_profile() instead of just
_get_color_profile(). Don't look at the preference setting because PSD
should behave more like "save" than "export" and save everything.
...export dialogs
Remove the "Advanced" expander from the PNG export GUI and generally
clean up the dialog layout.
Issue #701: Add a "Save color profile" toggle and always honor it.
...export dialogs
Move most stuff out of the "Advanced" expander, only nerdish encoding
options are left there.
Issue #701: Add a "Save color profile" toggle which honors the default
value configured in preferences and always saves the profile when
enabled.
As I did on app/, finalizing an output stream also implicitly flushes
and closes it. Hence if an export ended with an error, we'd end up with
incomplete data file (possibly overwriting a previously exported image).
Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
The later one don't even clean up its memory (which somehow is good here
as at least the output stream is never finalized hence sane files are
not overwritten in case of errors). As for the former (TIFF plug-in), it
doesn't even seem to have any error control AFAICS, apart from printing
error messages on standard error output.
Nothing said what was going to be the order of the page, except by
testing. Now there will be an explicit text, which will be automatically
updated when checking the "reverse order" box.
Commented out the inactive plug-ins registry: no point linking to a dead page.
Added links to the roadmap page, main wiki page, and the bug tracker. Placed
the link to the bug tracker one level up from '<Image>/Help/GIMP Online'
to make it more visible.
... only shows the color (and nothing else) when "Convert bitmaps to
vector graphics where possible" was set.
This is because gimp_drawable_histogram() only checks selected pixels.
So let's make sure we work on a duplicate of the image so that we can
safely remove the selection before processing the export.
(cherry picked from commit 679e341285)
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
Use the default APIs using GimpRGB and GimpHSV structs instead.
This also changes/fixes the colors in all affected plug-ins which were
broken/restricted in hue range ever since the _int() functions were
changed from a 0..255 to 0..360 hue range 15 years ago in commit
d93c2f61c8.
Add missing fclose invocations and fix copy-paste issue.
This issues has been discovered by coverity scan proceeded by Red Hat.
Fixed some mistakes in the patch and added more fclose() (Mitch)
(cherry picked from commit 56c8f8320d)
script-fu used to query the information of every PDB procedure on
startup, in order to get the number of parameters for each
procedure. This was done so that nullary procedures were defined
in such a way as to accept (and ignore) any number of arguments
(and at least one of the scripts we ship relies on this behavior).
However, this requires expensive back-and-forth communication with
the main GIMP process, which notable slowed down script-fu's
startup, and had a non-negligible impact on GIMP's startup time.
Instead, avoid querying procedure information, and implement the
special behavior for nullary procedures at call time. We do this
by defining, in addition to the "strict" gimp-proc-db-call
procedure, a "permissive" -gimp-proc-db-call internal procedure,
and using the latter to call the predefined PDB procedures.
After Dirk Farin had another look in the specs, it turns out that "mif1"
is actually allowed as major brand for HEIF. Also adding "msf1" which is
the equivalent for image sequences.
Just looking for "ftyp" would also match other ISOBMFF files (.mov or
.mp4 files for instance). These are the possible 4-byte "brand" code
which can follow "ftyp", as listed by Dirk Farin from libheif.
I add the "mif1" brand, as I encountered some files using this magic
(even though this should normally not be valid apparently, yet the file
loaded fine in GIMP).
This is not perfect as the standard allows potentially very big box
headers, in which case 8 bytes (the "largesize" slot) may be inserted
between "ftyp" and the brand, as I understand it. But this is actually
unlikely enough to probably never happen (the compatible brands list
would have to be huuuge, as it looks like this is the only extendable
part in a ftyp box). So let's assume this just never happens.
See also: https://github.com/strukturag/libheif/issues/83
Adding a magic number for HEIC/HEIF, which would allow to discard
obvious non-HEIC images even with the wrong extension.
Note: it looks like this magic number would also match more generically
other ISO base media file format (ISOBMFF) formats, like .mov or .mp4
files. I am enquiring for better magic but for now, this is better than
nothing.
