search

google / libultrahdr

Ultra HDR is a true HDR image format, and is backcompatible. libultrahdr is the reference codec for the Ultra HDR format. The codecs that support the format can render the HDR intent of the image on HDR displays; other codecs can still decode and display the SDR intent of the image.
https://developer.android.com/guide/topics/media/platform/hdr-image-format
Apache License 2.0
142 stars 24 forks source link

Encoding error #69

Closed suhailphotos closed 2 months ago

suhailphotos commented 6 months ago

I encountered an issue when combining the SDR base image with the YUV image. The error I received was "Encountered error during encodeJPEGR call, error code -20002." Interestingly, when I re-exported from Photoshop at a lower quality, everything worked smoothly.

I'm unsure if the problem is related to file size or chroma sampling rates like 4:2:0, or if there's another factor I'm not aware of. I've attached all four images for your reference.

File details:

  1. Source (quality set to maximum -12): trin_rain_acr_3d_gainmap.jpg (3D gain map from Adobe Camera RAW 16.2)
  2. YUV Conversion using FFMpeg: trin_rain_converted_using_ffmpeg.yuv
  3. High-Quality SDR base (output from FFmpeg): trin_rain_base_sdr_high_quality.jpeg
  4. Low-Quality (set to 5) re-export from Ps: trin_rain_base_sdr_low_quality.jpg

Combining images 2 and 3 failed, but combining 2 and 4 was successful.

The command used to run libultrahdr was: ./ultrahdr_app -m 0 -p trin_rain_converted_using_ffmpeg.yuv -i trin_rain_base_sdr_high_quality.jpeg -w 1080 -h 1350

FFmpeg version used: 6.1.1

Here is the link to the images: images link

ram-mohan commented 5 months ago

@suhailphotos Thank you for raising this issue. I have looked at the shared images. The problem is trin_rain_base_sdr_high_quality.jpeg internal color format is yuv444. Currently library is handling jpeg inputs with subsampling format yuv420 only. Hence during the decode, library is throwing the error you pointed. Supporting other sampling formats (422, 444, ...) does not require much changes. We will update the library to handle the same.

DichenZhang1 commented 2 months ago

Hi @ram-mohan @suhailphotos,

I believe this issue was fixed by one of our recent update. Could you check if we can close this issue?

Thank you!

ram-mohan commented 2 months ago

@DichenZhang1 Some more changes are needed. We are decoding the file but the data is 444. GenerateGainMap has to make use of this correctly. Currently I am working on this.

DichenZhang1 commented 2 months ago

@ram-mohan OK thanks for the update!