HDR Shows for 2-3 seconds then switches back to SDR when viewing on smartphone (S24)

[jeanrenaud]

I tried the ULTRA HDR generation and it seems to be somewhat working, but with a glitch. When I view the image on my Samsung Galaxy S24 smartphone, the HDR Highlights show at first, but after 2-3 seconds, the highlights disappear and we get to see the SDR version. It does that in the S24 Gallery App, ans also in Google Photos App.

Did someone experience the same thing ?

I've tried looking at pictures shot with the phone, and the HDR hightlights stays on forever. I also tested the Google Photos App to add HDR highlights into a non HDR image, and the added HDR stays there as long as the image is shown.

Here is what i tested :

• HDR-Only Mode : Tested with several "Display peak brightness", from 203 nits (the minimum in the script) to 10000 nits (the maximum), and tested with different "gain map downsampling steps". The issue occurs whatever the settings are. I also tried to apply a -5.62 EV exposure to the HDR file, but DarkTable only allow down to -3 EV. It would be advisable to explain how to get to -5.62 EV. I tested with a DNG as the HDR source.
• SDR-Only Mode : Tested with several nits, min/max content boost & min/max HDR capacity, issue still persists. Tested with RAW and JPG (separate tests) as source.
• SDR+Gain map : Tested with two JPGs, not much playing with boosts there since this is the same code than SDR-Only
• HDR+SDR : Tested with DNG + JPG. Not played much with the other settings since this is the same workflow than HDR-Only.

I'm not sure if it's because some EXIF Data is missing, i've found these EXIF data in a S24 Generated file which are not present in the Exif from libultrahdr (i excluded those who does not matter as i think) :

Chromatic Adaptation     : 1.04781 0.02289 -0.05013 0.02954 0.99048 -0.01704 -0.00923 0.01505 0.75214
Directory Item Length    : 23649
Directory Item Mime      : image/jpeg, image/jpeg
Directory Item Semantic  : Primary, GainMap
Exif Byte Order          : Little-endian (Intel, II)
Exif Image Height        : 3000
Exif Image Width         : 4000
Exif Version             : 0220
Gain Map Image           : (Binary data 23649 bytes, use -b option to extract)
Light Value              : 3.0
Thumbnail Image          : (Binary data 51633 bytes, use -b option to extract)
Thumbnail Length         : 51633
Thumbnail Offset         : 844
Version                  : 1.0
White Balance            : Auto
XMP Toolkit              : Adobe XMP Core 5.1.2
Y Cb Cr Positioning      : Centered

The following EXIF TAGS are present in both files but their values differ (i excluded the stuff that differ for a good reason like file sizes) :

• Rendering Intent : Set to "Perceptual" by the S24, set to "Media-Relative Colorimetric" by libultrahdr
• Profile Description : Set to "DCI-P3 D65 Gamut with sRGB Transfer" by S24, set to "Display P3 Gamut with sRGB Transfer" by libultrahdr

[gregbenz]

@jeanrenaud Anytime the image is changing, that behavior comes from the device (not the gain map - though it may be using it, such as when iPhone ramps from SDR to HDR in some cases). The exports from libultradr are good and would be supported by S24 (I'm not aware of any encoding options which are not supported there, but if it failed you'd simply see SDR only - not a changing appearance).

I've never heard of the behavior you're describing (and I have an S24 myself). That's a pretty odd response. Fading from HDR to SDR would be expected if the ambient light increases significantly (which will brighten the screen and reduce headroom) or if the devices switches into low power mode, but neither sounds like your scenario. I'd make sure you're updated to the latest OneUI in case where was some old bug which has since been fixed.

If you believe the image is unsupported, you could share one which consistently shows this behavior on an S24 to be validated on another device.

You might also view the image in Lightroom with HDR mode enabled in the light tab on your phone to try alternative decoding software (Chrome may use the same code given it and Android are Google). Adobe recently updated support to include S24.

[jeanrenaud]

You could certainly look at the attached files (see next reply). I've taken two pictures (one with S24, one with Canon Camera), and processed the Canon one with libUltraHDR_App.exe built from most recent release. I also attached original SDR File from Canon.

I extracted an XML Layout for the S24 and "libUltraHdr processed" images, using "exiftool.exe", the command line being :

exiftool -X -ee -k [image file] > [output xml file]

In the file coming from the S24 Phone, we see all expected headers including the "XMP Section" :

<XMP-x:XMPToolkit>Adobe XMP Core 5.1.2</XMP-x:XMPToolkit>
<XMP-x:XMPToolkit>Adobe XMP Core 5.5.0</XMP-x:XMPToolkit>
<XMP-hdrgm:Version>1.0</XMP-hdrgm:Version>
<XMP-hdrgm:Version>1.0</XMP-hdrgm:Version>
<XMP-hdrgm:GainMapMin>0.000000</XMP-hdrgm:GainMapMin>
<XMP-hdrgm:GainMapMax>2.300000</XMP-hdrgm:GainMapMax>
<XMP-hdrgm:Gamma>1.000000</XMP-hdrgm:Gamma>
<XMP-hdrgm:OffsetSDR>0.000000</XMP-hdrgm:OffsetSDR>
<XMP-hdrgm:OffsetHDR>0.000000</XMP-hdrgm:OffsetHDR>
<XMP-hdrgm:HDRCapacityMin>0.000000</XMP-hdrgm:HDRCapacityMin>
<XMP-hdrgm:HDRCapacityMax>2.300000</XMP-hdrgm:HDRCapacityMax>
<XMP-hdrgm:BaseRenditionIsHDR>False</XMP-hdrgm:BaseRenditionIsHDR>
<XMP-GContainer:ContainerDirectory>
  <rdf:Bag>
    <rdf:li rdf:parseType="Resource">
      <XMP-GContainer:Item rdf:parseType="Resource">
        <XMP-GContainer:Mime>image/jpeg</XMP-GContainer:Mime>
        <XMP-GContainer:Semantic>Primary</XMP-GContainer:Semantic>
      </XMP-GContainer:Item>
    </rdf:li>
    <rdf:li rdf:parseType="Resource">
      <XMP-GContainer:Item rdf:parseType="Resource">
        <XMP-GContainer:Length>23649</XMP-GContainer:Length>
        <XMP-GContainer:Mime>image/jpeg</XMP-GContainer:Mime>
        <XMP-GContainer:Semantic>GainMap</XMP-GContainer:Semantic>
      </XMP-GContainer:Item>
    </rdf:li>
  </rdf:Bag>
</XMP-GContainer:ContainerDirectory>

However, in the XML File generated from "libUltraHDR processed image", the XMP section is not visible. and we can't even see the "Min/Max Content boost" and "Min/Max HDR Capacity". But we can actually extract these values using ultrahdr_app in "decode" mode, and the "MP Image 2" section is there.

Obviously the Phone sees the "MP Image 2" and figure this is the gainmap. But does the Exiftool show there is something badly arranged in the file, that could cause that weird behavior ?

[jeanrenaud]

UltraHDR_S24_Vs_libUltraHdr.zip

[jeanrenaud]

I also used the following command line to get only the xmp headers :

exiftool -xmp -X -b -ee [image file] > [xml file]

And there is nothing extracted from the "libultrahdr processed" image.

[gregbenz]

@jeanrenaud Those images are show correctly on S24 in both Google Photos and Lightroom (display as HDR and stay that way). Any dimming you see is some issue specific to your device.

[jeanrenaud]

Is this setting toggled ON on your phone ?

Settings > Advanced Features > Super HDR

[jeanrenaud]

Ok, so... I retested everything and I made a bad evaluation. Here is what i observed :

• In "Google Photos", the HDR Image created by "libultrahdr" shows correctly.
• In the "Samsung Gallery App", the HDR Image created by "libultrahdr" DOES NOT WORK. It seems to work for a couple of seconds because i was testing it in a weird way; when opening Sansung Gallery App, if the first image shown is a "libultrahdr" one, it will not show in HDR. If we switch to another HDR image that was taken with the phone, the Scren will ramp up to the HDR Brightness. If the we switch back to a "libultrahdr" image, the HDR Brightness will stay for 2 seconds but the screen then ramps down to SDR brightness.

It seems this issue was discovered by other people - that Samsung Gallery App is messy.
https://www.reddit.com/r/samsunggalaxy/comments/1dmrb8k/the_messy_state_of_hdr_on_samsung_galaxy_phones/

Furthermore, i've looked at the binary code of several JPG files (after studying the JPG encoding structure on different sources) and it seems i've found what is the difference between "Samsung HDR Photos", "Google Photos HDR Enhanced images" and "libultrahdr generated HDR images" :

• Samsung Camera App creates the HDR Images using both "XMP Metadata" and "ISO 21496-1" formats
• Google Photos creates the HDR Images using both "XMP Metadata" and "ISO 21496-1" formats
• libultrahdr creates the HDR Images using only "ISO 21496-1" format

So what i think is that Samsung Gallery App is just looking for the "XMP Metadata" to determine if it is an HDR image, ignoring the "ISO 21496-1" header . If there is only the ISO 21496-1 header, then the image is considered to be SDR.

So you are right, this is specific to my device. But in theory, you should observe the same issue if you view the images in "Samsung Gallery app".

[gregbenz]

Libultrahdr can encode ISO, XMP, or both. Just pick the options you want in the code before compiling.

Most decoders support ISO and it is definitely the way forward. If the Samsung app won't read it, I'd report it as a bug, Android generally support ISO - but Samsung phones have been lagging behind Pixel and don't always have the latest "Android" support.

[jeanrenaud]

Good news ! With this flag enabled, HDR Image shows on both Samsung Gallery App and Google Photos App.

I had to also add "--useBaseColorSpace 1" value in the XMP metadata, for the XMP flag to work.

I was not sure how to apply the XMP Flag, i understood that i had to specify a build option, but i'm not sure about the command line format for this, so i just messed with the code. And the --useBaseColorSpace thing, i added it in the lua script, i would have expected the "ultrahdr_app" to add it itself if the XMP flag is ON, but i guess it did not because it's expecting the XMP flag to be entered as a command line option ?