Convert(Image, ...) problem on IJulia

[dprn]

Hi all,

on a clean IJulia notebook, executing the following

using Images
convert(Image, randn(256,256))

returns

WARNING: InexactError()
 in trunc at float.jl:374
 in copy! at abstractarray.jl:310
 in convert at array.jl:239
 in _convert at ~/.julia/v0.4/Images/src/core.jl:426
 in save_ at ~/.julia/v0.4/QuartzImageIO/src/QuartzImageIO.jl:258
 in getblob at ~/.julia/v0.4/QuartzImageIO/src/QuartzImageIO.jl:282
 in save at ~/.julia/v0.4/QuartzImageIO/src/QuartzImageIO.jl:48
 in save at ~/.julia/v0.4/FileIO/src/loadsave.jl:95
 in writemime at ~/.julia/v0.4/Images/src/writemime.jl:30
 in base64encode at base64.jl:160
 in display_dict at ~/.julia/v0.4/IJulia/src/execute_request.jl:32
 in execute_request_0x535c5df2 at ~/.julia/v0.4/IJulia/src/execute_request.jl:212
 in eventloop at ~/.julia/v0.4/IJulia/src/IJulia.jl:141
 in anonymous at task.jl:447
Trying next loading library! Please report this issue on the Github page for QuartzImageIO

before showing the correct result.

The same command on the REPL runs just fine.

[cstjean]

Thank you for the bug report. This is something I should fix.

When you run that code in IJulia, it attempts to display the image, triggering the save call, and it seems that this function doesn't support floating-point images. If you add a ; at the end of that line, the error goes away. Do you import QuartzImageIO? If you don't need it, then you may try not importing it and falling back on ImageMagick instead. I thought that we could convert to a fixed point representation with this code:

using Images, Colors, FixedPointNumbers
im1 = convert(Image{RGBA{UFixed8}}, randn(256,256));

But it throws an InexactError, and I don't know how to get around it. Anyone?

[cstjean]

On further investigation... randn returns normally-distributed numbers, so they are not in the [0, 1] interval, which is required for fixed-point conversion. If I replace randn with rand, QuartzImageIO works fine.

@timholy Are floating-point images with values outside of [0.0, 1.0] valid? Should we just clamp them?

[timholy]

Do you import QuartzImageIO? If you don't need it, then you may try not importing it and falling back on ImageMagick instead.

Now there should be no need for an explicit import of either QuartzImageIO or ImageMagick. I can't remember what happens if an OSX user says using ImageMagick, whether that will be preferred over QuartzImageIO. (Maybe someone can test.)

Are floating-point images with values outside of [0.0, 1.0] valid? Should we just clamp them?

There's the Clamp01NaN type for that purpose, see JuliaIO/ImageMagick.jl#18. I'm not sure what the best default is for IJulia; should be done by default, or not? (If we decide "yes," it's just a matter of changing the default for this function.)

[cstjean]

I can't remember what happens if an OSX user says using ImageMagick, whether that will be preferred over QuartzImageIO. (Maybe someone can test.)

On my machine (OSX), even with using ImageMagick it tried QuartzImageIO first.

[timholy]

That may be OK, but perhaps we want to modify FileIO so it checks already-loaded modules first. Thoughts, @SimonDanisch?

[SimonDanisch]

Ah yeah, that was on the imaginary TODO list... The worst part is, that the behaviour is then dependant on global state. Which might be okay? We should offer a way to force the IO library anyways, so people who really care about the choice of IO library are not bitten by some other package having using ImageMagick in the code.

[timholy]

Yeah, you're right that it's probably better to have {default|force|delete}_library(format, module, args...) commands that manipulate the list of options.