HDR files written by JP can't be reliably displayed by OS X 10.9 preview

Question

HDR files written by JP can't be reliably displayed by OS X 10.9 preview

blitzcode opened this issue 10 years ago · comments

HDR images written JP cause all sorts of strange behavior with Maverick's preview application, like:

Fully black rectangular image flat out crashes Preview (Ok, that one pretty much has to be at least partially bug in Preview)
An image with an HDR photograph in it shows up black
An image consisting of 6 different colors shows up with a darkened circular area in the center

I tried loading some of the files with some old C++ HDR loading code I've written. Some work, some don't, others crash the reading code.

This image crashes my (old, perhaps really wrong) reading code and shows up back in Preview:

http://www.blitzcode.net/stuff/scaling_test.hdr

I noticed messing with the exposure in Preview makes the upper half of the image show up, while the lower half seems truly black. Using JP's saveBmpImage instead of saveRadianceImage writes the image out correctly.

This image has six different regions each with a solid color. Loads fine with my HDR loading code, has a strange dark circular spot in the center in Preview:

http://www.blitzcode.net/stuff/scaling_test_2.hdr

Tim C. Schröder · Answer 1 · Fri Aug 22 2014 20:46:50 GMT+0800 (China Standard Time)

Just tried reading the JP written HDR with the free 'Luminance HDR 4.2.0' program:

IOWorker: caught exception reading /Users/Tim/scaling_test_scaled.hdr: RGBE: difference in size while reading RLE scanline

Vincent Berthoux · Answer 2 · Sat Aug 23 2014 15:29:26 GMT+0800 (China Standard Time)

I'm gonna look at the issue

Vincent Berthoux · Answer 3 · Sat Aug 23 2014 17:28:15 GMT+0800 (China Standard Time)

Could you post the code used to generate the HDR? Debugging with the resulting HDR file will be hard.
Could you also send me 'Luminance HDR' programm for OSX? I'm not able to download it for sourceforge for unknown reason.

Tim C. Schröder · Answer 4 · Sat Aug 23 2014 18:06:17 GMT+0800 (China Standard Time)

This simple black image is the one crashing Preview:

JP.saveRadianceImage "./tmp.hdr" . JP.ImageRGBF $ JP.generateImage (\_ _ -> JP.PixelRGBF 0 0 0) 256 128

JP itself can load it back fine, though. I was able to find a few cases where JP couldn't load back the image it wrote itself ("HDR Out of bound HDR scanline 987 (max 512)", so this should be in theory debuggable without access to any other HDR viewer), but unfortunately nothing that could be sanely extracted into a small reproduction case. The error certainly depends on the image content, like I can write 5 equally sized images just fine and the 6th can't be read back anymore. I'll keep trying and see if I can make it trigger reliably.

Vincent Berthoux · Answer 5 · Sat Aug 23 2014 18:07:37 GMT+0800 (China Standard Time)

Hmm, I smell a bug in the RLE encoder, I'm digging

Vincent Berthoux · Answer 6 · Sun Aug 24 2014 22:12:05 GMT+0800 (China Standard Time)

I'm a little concerned, I've played with the black radiance image like the following:

badRadiance :: IO ()
badRadiance = do
  let filenameOf ix =
        "tests" </> "radiance" </>
            (printf "radiance_black_%03d_.hdr" ix)

  forM_ [1 .. 255] $ \width -> do
    saveRadianceImage (filenameOf width) . ImageRGBF $
        generateImage (\_ _ -> PixelRGBF 0 0 0) width 1

  forM_ [1 :: Int .. 255] $ \width -> do
    rez <- readHDR $ filenameOf width
    case rez of
      Left err -> putStrLn $ printf "Failed to read %03d: %s" width err
      Right _ -> putStrLn $ printf "OK %03d" width

JP can reload all the written files. For Preview, It can loads fine with sizes up to 7 but once the run goes above or equal 8, preview crash. After a diff between the 7 and 8 version:

For 'Luminance HDR 2.4.0', it can load the 8x1 image, but not the version with 50 pixels:

I've tested LizardQ Viewer, and he seemed to be ok with the various radiance files. I don't see something obvious I've missed, I'm taking any idea there. I'm thinking about adding a "stupid" writer to write uncompressed images, to be at least able to let them be viewable in Preview.

I'm running OSX 10.9.4 with Preview 7.0 (828.4)

Tim C. Schröder · Answer 7 · Mon Aug 25 2014 02:03:43 GMT+0800 (China Standard Time)

That is indeed rather strange. I'm sorry I haven't given you any more info (ran out of time to work on my project dealing with HDR files for this weekend), but I'll continue to look into this next week. I also noticed that different file dimensions seem to matter. I personally think the RLE encoding is rather pointless for HDR files anyway, just a bunch of needless complexity. I checked the HDR C++ code I wrote a couple of years ago, apparently I did not implement RLE for writing out files.

Vincent Berthoux · Answer 8 · Thu Aug 28 2014 01:24:53 GMT+0800 (China Standard Time)

I've reported the problem via the Apple bugtracker, and they're teling me that they can't reproduce the issue. If you got example of file I can't reload, I'd be really interested. For the preview case, I'll provide a "write uncompressed" and that's it.

Tim C. Schröder · Answer 9 · Thu Aug 28 2014 04:37:20 GMT+0800 (China Standard Time)

That's a bummer. I tried finding some bugs by adding random gradients or repeated runs of different pixels to your testcase, no luck. Also, I've been caching and reloading things in HDR format in my project for the last two days and had no issues. I think it's perfectly likely that Preview, my old HDR code and Luminance HDR have a bug in the decoder. I think adding a no-RLE mode for better compatibility would be a nice addition, typical HDR images don't benefit much from it anyway.

Vincent Berthoux · Answer 10 · Sun Aug 31 2014 05:29:46 GMT+0800 (China Standard Time)

I've just released JuicyPixels 3.1.7 with the fix, I'm closing this ticket.

Tim C. Schröder · Answer 11 · Sun Aug 31 2014 14:53:18 GMT+0800 (China Standard Time)

Thank you so much! ;-) I just bumped my project's dependency, will let you know if I run into any further issues.