readHDR seems to be broken

[fhaust]

After writing an image with writeHDR and reading it back with readHDR the image is blank (full of zeros). This happens with version 3.2.5.1.

Code to reproduce:

import Codec.Picture
import Codec.Picture.Types

import Control.Monad
import Control.Monad.Random

main = do

  -- generate random image
  randomData <- take (128*128) <$> getRandomRs (0,1) :: IO ([Float])

  -- create image
  let imageF = generateImage (\x y -> randomData !! (x + 128 * y)) 128 128

  -- convert to valid hdr format
  let imageRGBF = promoteImage imageF

  -- write image to disk
  writeHDR "image.hdr" imageRGBF

  -- read back image
  (Right (ImageRGBF imageRead)) <- readHDR "image.hdr"

  -- imageRead is now full of zeros
  guard (imageData imageRGBF == imageData imageRead)

[Twinside]

I don't get full zero with this:

randomTest :: IO ()
randomTest = do
  randomData <- take (128*128) <$> getRandomRs (0,1) :: IO ([Float])
  let imageF = generateImage (\x y -> randomData !! (x + 128 * y)) 128 128
  let imageRGBF = promoteImage {- edit -} imageF
  writeHDR "image.hdr" imageRGBF
  (Right (ImageRGBF imageRead)) <- readHDR "image.hdr"
  -- readBack is not full black.
  writeHDR "readBack.hdr" imageRead
  print $ V.all (<= 0) $ imageData imageRGBF
  print $ V.all (<= 0) $ imageData imageRead
  guard (imageData imageRGBF == imageData imageRead)

The HDR format is not loss less, so you can expect small differences with what is encoded and what is read back (add in to the mix equality on Float, which is not a good idea). Moreover the format is intended for high dynamic range, if you stay in the [0; 1] range, this is clearly not a good format

[fhaust]

So this is expected behavior? I thought HDR would just take my floats and store them.

[0;1] was just for datas sake. But I just tried with [0;2^16-1] and still get a result that is just zeros.

I just tried your code and I think it is not runnable as is: imageRGBF is Image PixelF which is not writable by writeHDR. Are you using a development Version of JuicyPixel? If I change that I get False\nTrue\*** Exception: user error (mzero), so the data that was read back is all zeros.

Is JuicyPixels dependent on any external libraries? Maybe i have some incompatible library installed in the system. This is Arch Linux current as of today.

2015-06-11 13:36 GMT+02:00 Vincent notifications@github.com:

Closed #98 https://github.com/Twinside/Juicy.Pixels/issues/98.

— Reply to this email directly or view it on GitHub https://github.com/Twinside/Juicy.Pixels/issues/98#event-328393080.

[Twinside]

Sorry copy paste error, the promoteImage has jumped, I've edited the code.

Your result is weird, I have False, False on my machine, and I use the current HEAD of the repository, but the HDR part hasn't changed in ages...

On my current machine, I'm using GHC 7.6.3, I can try with GHC 7.10 tonight

[fhaust]

Edit: this was in response to the "what makes you think you have just zeroes?" line. I think the comment above was edited, but I responded to the email. Just to avoid confusion.

When I look at imageData imageRead the ghci console fills with zeros ;)

I made a video ... for your viewing pleasure ;) https://dl.dropboxusercontent.com/u/2359191/jp-hdr-test.mp4

2015-06-11 14:22 GMT+02:00 Vincent notifications@github.com:

Sorry copy paste error, the promoteImage has jumped.

But what makes you think you have just zeroes?

— Reply to this email directly or view it on GitHub https://github.com/Twinside/Juicy.Pixels/issues/98#issuecomment-111113789 .

[Twinside]

Nice wallpaper, but it's not really helpful, I don't have a video player that let me zoom, what is your version of GHC?

[fhaust]

Ah sorry ... unusual monitor configuration ... nevermind, that was just to confirm that I just get zeros.

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.1

(Unrelated: Wallpapers randomly drawn from Reddits EarthPorn channel by a little script I wrote: http://lpaste.net/134333)

[Twinside]

I can't reproduce with GHC 7.10.1 x86 on windows, are you using a x64 version?

[fhaust]

This was on Linux 64bit. Am 12.06.2015 18:08 schrieb "Vincent" notifications@github.com:

I can't reproduce with GHC 7.10.1 x86 on windows, are you using a x64 version?

— Reply to this email directly or view it on GitHub https://github.com/Twinside/Juicy.Pixels/issues/98#issuecomment-111538441 .

[Twinside]

I've reproduced the problem with GHC 7.10.1 x64 on Windows, I'm currently trying to reduce the test case to find the problem.

[Twinside]

Here is the reduced test case highlighting the difference between 64bits and x86 on GHC 7.10.1

import Data.Word( Word8 )

-- removing the bang patterns on V definition makes
-- the problem go away.
data V = V !Word8 !Word8 deriving Show

toV :: Float -> V
toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where
  coeff = significand d *  255.9999 / d

main :: IO ()
main =
  print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ]

The problem appears at the following optimisation levels:

• -O1
• -O2
• -O3 (may be the same as -O2)

No problem at -O0 x86 result:

[V 145 124,V 189 128,V 137 128,V 132 126,V 233 127]

x64 result:

[V 0 124,V 0 128,V 0 128,V 0 126,V 0 127]

[fhaust]

Outch ... would you be so kind as to open a bug report there?

[Twinside]

Let's hope for some results for this GHC ticket

[Twinside]

I've just tested with GHC 7.10.2RC1 and the problem is also present

[Twinside]

I've just tested with the last GHC 7.10.2 RC 2 x64 on windows, and the bug is fixed, as the GHC ticket opened.

So closing this ticket, that was a weird one :]

[fhaust]

Nice. Nobody expects compiler errors. Am 04.07.2015 10:03 schrieb "Vincent" notifications@github.com:

Closed #98 https://github.com/Twinside/Juicy.Pixels/issues/98.

— Reply to this email directly or view it on GitHub https://github.com/Twinside/Juicy.Pixels/issues/98#event-347743081.