heif_chroma_interleaved_24|32bit are deprecated values replaced by
heif_chroma_interleaved_RGB(A).
Also we allocated a HEIF context twice (i.e. leaking it).
Finally it's better to initialize heif_image and heif_encoder variables
to NULL because these may not be set if creation functions fail (and
it's better to fail with NULL than with garbled unset contents).
- Add the quality slider in a frame under the "lossless" checkbox,
making the relationship more obvious.
- Make the whole frame contents insensitive when "lossless" is checked
and not just the slider. Once again, it makes the relationship more
obvious.
- Add a mnemonic to the "Lossless" checkbox and "Quality" slider.
...always AdobeRGB!
Change all file plug-ins to never call gimp_image_metadata_load_finish()
with the GIMP_METADATA_LOAD_COLORSPACE when they loaded a color profile.
This keeps gimp_image_metadata_load_finish() from assigning a profile
from DCT even if the loaded profile was GIMP's built-in sRGB.
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.
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.
There is something broken in the obscure "text_column" and
"pixbuf_column" code in GtkIconView, and I don't have the nerve to
debug it.
Enable opening an image on activation (double click).
Current code was only taking into account cancelation, so we could end
with weird plug-in return:
> HEIF/HEIC plug-in returned SUCCESS but did not return an image
Instead properly set an error status, and echo back the error from the
plug-in or libheif.
Thanks a lot to Dirk for contributing this, added him to AUTHORS.
Import the code from https://github.com/strukturag/heif-gimp-plugin.git
as of today. Merged the files into a single-file plug-in. Changed
the code a lot to match our coding style, but only formatting,
no logic changes.
Still uses deprecated GimpDrawable API and no GIO, but I wanted to do
actual code changes separately from the initial import. Also disabled
metadata support because updating that to GimpMetadata was too much
for the initial import.
