Dirk Farin

Found it. The bug is in lines like this: https://github.com/strukturag/libheif/blob/acdc8d9837fb75924ef25bebb964f363356c3d9c/libheif/codecs/uncompressed_image.cc#L640-L641 On BE, this copies the high-order byte of `val` into the output, which is always 0 for 8 bit components....

@bradh I'm currently trying to fix the endianness issue in the uncompressed codec because it is a blocker for the v1.19.0 release. I could fix the processing in the codec,...

The endianness issues should be fixed now (at least to make the tests run on ppc64). The `uncompressed_decode_generic_compression` test is still failing for me, but that is probably because I...

> Maybe the flags should be checked and files that are not big-endian should be rejected until support for this has been implemented? This could easily be done here: https://github.com/strukturag/libheif/blob/474d68b9c04e39b2bb07ff0a02ba1041a3370a6d/libheif/codecs/uncompressed/unc_codec.cc#L50-L51...

Right. Maybe a check could be added whether any component is >8bit so that 8bit still works with any endianness.

Added the check here: 4da2842

The quality settings are not comparable. 85 in libheif is not 85 in macOS. You need to find a compression setting that gives comparable output quality. That depends a lot...

libde265 is the decoder. You are probably using the x265 encoder.

I analyzed the file. It contains three thumbnails: - ispe: 1616x1080 (HEVC), id 11, stored size: 1664x1088 - ispe: 320x212 (HEVC), id 12, stored size: 320x256 - ispe: 160x120 (JPEG),...

If it is an error that affects many images, and I guess that the camera firmware is not easy to upgrade, we might consider to add an option to the...