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.
Use gimp_image_{freeze,thaw}_layers(), added in the previous
commit, to suppress updates to the Layers dialog while constructing
the decomposed layers, which significantly speeds up the operation
if the dialog is mapped.
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.
Some locales (like German) use ',' as the decimal separator, so using
printf like functions to output a float value fails when the result
should always use '.'. Since there are only two distinct possibilities
we just write the string representation and be done with it.
Exchanging with OpenJPEG developers and searching more on the topic, it
seems that YUV is more often refered to as YCbCr. Wikipedia says:
> typically the terms YCbCr and YUV are used interchangeably, leading to
> some confusion. The main difference is that YUV is analog and YCbCr is
> digital
As for eYCC, I am told this is extended YCC. It seems this is refered as
xvYCC (I really can't find much under "eYCC"). So let's rename it too.
Hopefully I made no mistakes!
JPEG 2000 codestream doesn't have a header and guessing the color space
in particular is not foolproof (especially when 3 or 4 components, which
can be many spaces). Therefore the need of a parameter on the API.
Note that JP2 images should always have the color space information. In
interactive mode, I try to be a bit flexible to salvage broken JP2 with
no color space information in the header, but I am not adding a
parameter in file-jp2-load() (on purpose, since we are not going to add
in the API a parameter for a case not supposed to happen with properly
encoded files).
JPEG 2000 codestream (.j2k/.j2c) are only compressed code stream data,
without header. In particular we don't have color information, such as
the color space. So we need to open a dialog asking to set the color
space in interactive mode.
Note: according to OpenJPEG developers, a JP2 image (not codestream)
should always have a color space defined in its header. But just to be
flexible, the same dialog may get raised as well if we try to load a JP2
with no valid color space defined in header and no ICC profile embedded.
Maybe if such a thing happened, it means the image is corrupt, yet we
may as well try and salvage it anyway.
Note 2: I also removed a weird test which was setting some images as
being YUV color space by mistake. This actually fixes bug 794413 as a
side effect.
Even though I haven't seen working samples with this extension,
according to some references, this is a common extension for compressed
JPEG 2000 code stream. Also our old plug-in was listing this extension,
so let's do so now as well.
To this day, the only 2 extensions we used to list in the JasPer-based
plug-in and not in the OpenJPEG one are .jpf and .jpx (JPEG 2000 Part-2)
since OpenJPEG does not have support yet. But actually I think the old
plug-in may have simply been "lying" since JasPer website says the
library is meant to implement JPEG-2000 Part-1 standard.
So I believe we are now on par (and even better on many aspects) with
the former plug-in implementation based on libjasper.
After moving up the profile extraction, I was running
gimp_image_set_color_profile() with a non-existing image id, which was
obviously wrong. Reorder a bit the operations.
Also try to guess the color space from the profile not only with
OPJ_CLRSPC_UNSPECIFIED but also OPJ_CLRSPC_UNKNOWN images. Indeed I
encountered a case of .jp2 image with no color space in the header, but
with an embedded profile. And unlike the .j2c files I encountered
earlier, the color space was now *_UNKNOWN.
See https://github.com/uclouvain/openjpeg/issues/1103
