Closed fhaust closed 9 years ago
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
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.
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
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 .
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?
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)
I can't reproduce with GHC 7.10.1 x86 on windows, are you using a x64 version?
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 .
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.
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]
Outch ... would you be so kind as to open a bug report there?
Let's hope for some results for this GHC ticket
I've just tested with GHC 7.10.2RC1 and the problem is also present
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 :]
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.
After writing an image with
writeHDR
and reading it back withreadHDR
the image is blank (full of zeros). This happens with version3.2.5.1
.Code to reproduce: