Add support for handling 'tmap' items #1503
Conversation
ram-mohan
force-pushed
the
master
branch
2 times, most recently
from
dce9a85 to
7440574
Compare
libheif/context.h
Outdated
| std::shared_ptr<ImageItem> get_primary_image(bool return_error_image); | ||
|
|
||
| #if WITH_EXPERIMENTAL_GAIN_MAP | ||
| std::shared_ptr<ImageItem> get_gain_map_image() { return m_gain_map_image; } |
There was a problem hiding this comment.
This only works if there is only a single gain map in the file. The gain map should probably be stored in the ImageItem like the alpha image or the depth map.
There was a problem hiding this comment.
Thank you for the review, As indicated, i have moved the gainmap info inside ImageItem
libheif/context.h
Outdated
| #if WITH_EXPERIMENTAL_GAIN_MAP | ||
| std::shared_ptr<ImageItem> get_gain_map_image() { return m_gain_map_image; } | ||
|
|
||
| std::shared_ptr<ImageMetadata> get_gain_map_metadata(); |
There was a problem hiding this comment.
Same here, the gain map metadata has to be part of ImageItem to work correctly when there are several images in a file.
|
Thank you. Note that there is also some work for this in #1121. I will have a closer look at this when we switched to the v1.20.x branch and can do API additions. |
Gain map technology offers a way to create an image (henceforth referred as derived image) from one base input image and a secondary input image called as a gainmap input image. Reconstruction is done by applying the gain map to the base image according to iso 21496-1 section 6. This change provides API to read, write base input image, gain map input image, gain map metadata. Third party applications can make use of this API to render only base image or reconstruct the derived image and render the same. By default these API is disabled and can be enabled at configure time using option -DWITH_EXPERIMENTAL_GAIN_MAP=1 TODO: add plugins for encoding, decoding uhdr images
|
Hi there, just wanted to check in on the progress of this. I realize that gain maps can already be decoded as generic auxiliary images, but I don't think it's possible to read gain map metadata without this PR's tmap item support (please let me know if I am wrong) -- that feature alone would already be very useful. Thank you! |
|
I rebased it on v1.21.2 here: https://github.com/fxthomas/libheif/tree/pr/1503-gain-maps-v1.21.2 A couple of warts in the API so far (I haven't touched most of the original branch, just moved things around when needed following changes in libheif
I verified that it is possible to re-encode an input HEIC+gain map file into a new HEIC+gain map file with almost identical data (the "except" is because of re-compression of the original decompressed data) and that both display identically on an HDR display. |
To make things worse, I encountered heic images in the wild whose |
|
After checking : the version I have access to (ISO/DIS 21496-1:2024 draft, which I unfortunately cannot link to here because ISO is not public access...) seems to mandate the presence of the version field. In my version this field also contains a struct of 2 big endian int16 values (which matches images generated by iOS devices, for example), but the original PR truncates a single uint8 value (an older revision of the draft?). Either way all things do point towards leaving interpretation outside of libheif (and not just for |
|
Yes, the two big endian int16 values are always included. What I am saying is that some heic files (notably ones from my iPhone) include an additional uint8 version (the one being skipped in this PR), whereas other heic files don't include the uint8 (notably from Hasselblad cameras). |
Ah, I found it elsewhere! ISO/IEC 23008-12 describes the structure of HEIF/HEIC files and the latest version describes how ISO 21496 is supposed to be implemented in those containers. While I only have a draft (I cannot check if it is still the case in the published version), the version I have has an uint8 version field marked as mandatory, which is then followed by the struct described in ISO 21496. I'm still in favor of just returning the whole data, but this explains why the PR truncated the field originally. |
|
Ooooh, thank you very much for the pointer! (Yet another document to purchase...) That at least settles which of the heic images are compliant.
FWIW, also still agreeing. Even if only for users to be able to read non-standard metadata. |
4 participants
Gain map technology offers a way to create an image (henceforth referred
as derived image) from one base input image and a secondary input image
called as a gainmap input image. Reconstruction is done by applying the
gain map to the base image according to iso 21496-1 section 6.
This change provides API to read, write base input image, gain map input
image, gain map metadata. Third party applications can make use of this
API to render only base image or reconstruct the derived image and
render the same.
By default these API is disabled and can be enabled at configure time
using option -DWITH_EXPERIMENTAL_GAIN_MAP=1
TODO: add plugins for encoding, decoding uhdr images