Lossless option switch to YUV444 format when save depth is 8bit.
I would like to enable YUV444 for 10,12bit depth
in the future too, but there is issue in libheif.
The lossless option does not provide true lossless encoding yet, unfortunately.
We must rename the string to correctly inform users that the compression is not 100% lossless,
Technically the image gets converted from RGB to YUV420 format (which is lossy operation itself) and only afterwards the data are compressed lossless-ly.
Backported features from master:
AVIF export (when built with >= libheif 1.8.0)
High bit export
User can select save bit depth (8, 10, 12) during export
Minor fixes in import
Back-porting some of the features from master:
AVIF import (need libheif >= 1.8.0)
High bit (10/12) import
NCLX color profile import (link with lcms)
Metadata import (link with gexiv2)
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).
(cherry picked from commit f4af95ab95)
- 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.
(cherry picked from commit 7f76430090)
Same as WebP or jpeg: follow explicitly assigned profile TRC; convert
default (non-assigned) profile to sRGB, except if work format is 8-bit
linear.
(cherry picked from commit 5d6baf5f85)
...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.
(cherry picked from commit a08293dc74)
Since this requires libheif 1.4.0, released end of February 2019, this
commit should not go into the gimp-2-10 branch right now.
(cherry picked from commit 22e14e0b9b)
Since this requires libheif 1.4.0, released end of February 2019, this
commit should not go into the gimp-2-10 branch right now.
(cherry picked from commit 22e14e0b9b)
Cherry-picked now anyway... If we allow new featues in 2.10, we must
also allow for a few updated dependencies.
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.
(cherry picked from commit 66ec467217)
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.
(cherry picked from commit 64b00b5c7f)
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
(cherry picked from commit 4ad3993eca)
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.
(cherry picked from commit d738d2f645)
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).
(cherry picked from commit 625aa514f6)
(picking the icon view change was not neccessary but this plug-in will
get more updates so let's keep the code in sync)
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.
