This is a follow-up from the previous post here.
I submitted two patches to FFmpeg to fix Nikon HEIF decoding, and they (first, second) got merged. With these, I can now decode straight-out-of-the-camera and regular-size .HIF files using FFmpeg, which is great!
With that out of the way, I could try decoding the scaled HEIF using FFmpeg and seeing if it chokes the same way as libheif does...
Metadata:
major_brand : heix
minor_version : 0
compatible_brands: mif1heixmiafMiHAjpeg
...
Stream #0:0[0x2000]: Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(pc, bt2020nc/bt2020/arib-std-b67), 320x214 ...
Stream #0:1[0x2001]: Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(pc, bt2020nc/bt2020/arib-std-b67), 1620x1080 ...
Stream #0:2[0x2002]: Video: mjpeg (Baseline) (jpeg / 0x6765706A), yuvj444p(pc, bt470bg/unknown/unknown), 160x107, ...
Stream #0:3[0x1000]: Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(pc, bt2020nc/bt2020/arib-std-b67), 1620x1080 ...
Stream mapping:
Stream #0:3 -> #0:0 (hevc (native) -> mjpeg (native))
It worked! It produces a recognizeable jpeg image:
So it appears libheif and/or libde265 might be doing something wrong (or maybe not working around a weird issue) instead of NX studio being wrong. Though, funnily enough, the thumbnails from the camera are preserved, so you can see above even though I resized the main image to 1620x1080, the original 1620x1080 thumbnail remains in the new file. They should probably do something about that; I don't think anyone needs two copies of the same image in the same file...
On a side note, that <pre> block looks pretty ugly and probably extends past the column bounds on your screen; I should probably look into a better method of displaying code blocks rather than just using the <pre> HTML tag by itself.