-
-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add experimental gain map support #1121
base: master
Are you sure you want to change the base?
Conversation
DichenZhang1
commented
Feb 2, 2024
This feature is hidden behind the WITH_EXPERIMENTAL_GAIN_MAP compile flag. See https://helpx.adobe.com/camera-raw/using/gain-map.html for an introduction to gain maps. Note that in this change, gain maps are not stored as auxiliary items as proposed by Adobe, but as a hidden input to a new 'tmap' (tone mapped) derived item. An 'altr' (alternatives group) box is also added to tell the decoder that it may show the tone mapped image (preferrably) or the base image as a fall back. The primary item id still points to the base image for backward compatibility.
This feature is hidden behind the WITH_EXPERIMENTAL_GAIN_MAP compile flag. See https://helpx.adobe.com/camera-raw/using/gain-map.html for an introduction to gain maps. Note that in this change, gain maps are not stored as auxiliary items as proposed by Adobe, but as a hidden input to a new 'tmap' (tone mapped) derived item. An 'altr' (alternatives group) box is also added to tell the decoder that it may show the tone mapped image (preferrably) or the base image as a fall back. The primary item id still points to the base image for backward compatibility.
Hi there! Can someone help to review this pull request? This is adding gain map support for HEIC and AVIF images. Thank you! |
Hi there! This change is adding support for encoding and decoding HEIC and AVIF with gain map images. Could anyone help to take a look and provide feedback? Thank you! |
Friendly bumping up again. Thank you! |
Thank you for the contribution. It generally looks good. The |
Is this standardized anywhere? Could you point me to the specification? The Adobe document says:
Does that mean that there is no final spec yet? We can include it as "experimental" anyway, but have to make it very clear that the spec is not finalized yet. Do you have any kind of test program? Maybe a patched |
Sync with main branch
Sync with main branch
Add verification code in heif_enc and heif_info
Hi Dirk, Thank you for looking into this! I've changed the Thank you! |
// Get id of the gain map image of the HEIF file. If no gain map image is available, this | ||
// method will return heif_suberror_No_item_data. | ||
LIBHEIF_API | ||
struct heif_error heif_context_get_gain_map_image_ID(struct heif_context* ctx, heif_item_id* id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume there can be several gain maps in the file. We should add the color image ID as another parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for the two functions below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is intended that we only support one gain map at most, and that gain map is for the primary image. Assume if we have multiple color images and multiple gain maps, and it is likely that users accidentally links one gain map to another gain map, and we can't detect that case.
But I agree that the standard is still in draft stage and this is not clearly defined. I think we can hold this for a little while and still mark this gain map support as "experimental".
@@ -517,6 +517,18 @@ static bool item_type_is_image(const std::string& item_type, const std::string& | |||
item_type == "mski"); | |||
} | |||
|
|||
#if WITH_EXPERIMENTAL_GAIN_MAP | |||
static bool item_type_is_gain_map_image(const std::string& item_type, const std::string& item_name) { | |||
return (item_name == "GMap" && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that images are not using a GMap
item_name
.
In issue #1190, there is an image with a gain map, but the items do not have the GMap
name. Instead, the gain map is linked with an auxl
reference with type urn:com:apple:photo:2020:aux:hdrgainmap
in the auxC
property. Thus, we might have to check that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is old legacy Apple GainMap HDR from iPhone 12+ heif images, and is already present pre-iOS 18 (it is present in my heic photos that I believe are from iOS 15, iPhone 13 mini).
While it would obviously be nice if libheif supported it as well, I do not think it has anything to do with the upcoming ISO standard.