Move away from ImageMagick

[timholy]

Relying on ImageMagick seems to be presenting problems for Mac users (see #15, #23), and also leads to slow performance. For at least PNG, JPG, and TIF it would be good to find an alternative, presumably by directly calling the corresponding libraries.

[timholy]

When this happens, add floating-point format to tiff.

[ihnorton]

Follow-up question: are you ok with bundling these wrappers in Images? I feel like ideally each binding would be available separately from Pkg (or an "ImageIO" package), but that might be a premature optimization at the moment esp. considering Pkg is a tad slow.

[timholy]

I think it may be best to bundle with Images. We already have an infrastructure that avoids loading format-specific code until it's needed, so it shouldn't bloat the time for using Images at all.

[timholy]

@ihnorton and I did some outside digging. libpng's error handling is really problematic because it uses setjmp and longjmp. I think we'd need to write a C wrapper and link against libjulia so we could have the error handler call jl_errorf. But that seems really problematic given that folks will use readline, debug, etc versions. The other alternative is to use a different PNG library. @ihnorton identified a couple such projects.

This has me leaning towards an overall wrapper, either OpenImageIO (as suggested by @ihnorton), FreeImage, or ImageMagick's C API. OpenImageIO looks like the nicest and most actively-maintained of these, but it's a C++ library which could be trouble. (On the other hand, maybe a good excuse to polish C++ infrastructure.) OpenImageIO uses a BSD license; the other two use their own licenses, and they seem fairly permissive but I'd guess they are not MIT-compatible.

[timholy]

I've played a little with OpenImageIO, and even on a Kubuntu 12.04 machine it seems a little nontrivial to build. It appears to require at least a more modern OpenEXR than comes with 12.04. This does suggest that we might need to build the whole library as a binary on all platforms, and if we want to support a lot of file formats this would mean it won't be insignificant to put this together.

[ihnorton]

MIT-compatible or GPL-compatible?

The ImageMagick license looks fine (attribution clause does not exclude MIT). Furthermore, runtime linking is explicitly stated to not constitute derivation.

The FreeImage license looks fine also, it is LGPL-like (modifications must be distributed, but presumably we won't make any). stackoverflow thinks it is MIT compatible, FWIW.

[timholy]

Thanks, that's very helpful. Of course you're right that we presumably don't need to worry about redistribution, it's likely we'll simply link (hence LGPL is not actually restrictive).

[ihnorton]

[edit] Thanks to @vtjnash's help and suggestions regarding setjmp, it looks like this is tractable. The setjmp returns properly when I create an error condition by passing a jpeg instead. Note that the setjmp must be a real ccall inside of the if block. If you make a setjmp(buf) = ccall(...) function like I originally did it will segfault, I guess because it needs to be inline.

[ihnorton]

(the get_width and get_height functions work correctly too; haven't gone further than that yet)

[vtjnash]

@ihnorton I probably should have mentioned that: the function that called setjmp must not return, or it will destroy the stack that it is meant to preserve.

[timholy]

Unless we want to use a wrapper, there's still the problem that the jmp_buf in png_struct appears to be machine-dependent.

ATM I'm exploring ImageMagick's C interface, since my worry is that if PNG and JPEG are presenting challenges, how likely is it that other formats won't present their own idiosyncrasies? This obviously doesn't constitute "moving away from ImageMagick", but the biggest problem with our usage of IM has been the Cmd interface. Wrapping the C library directly should get rid of that problem.

That said, jpeg-turbo may be faster than IM, and that would be a good thing. In other words, I'm viewing IM as a generic fallback as much as anything.

I'm not currently planning to wrap any more of IM than the image loading/unloading code (which looks like ~10 functions).

[ihnorton]

Unless we want to use a wrapper, there's still the problem that the jmp_buf in png_struct appears to be machine-
dependent.

True, but we don't have to allocate it ourselves.

[timholy]

But since it's at the top of the png_struct, we won't know the byte-offset of any of the other elements.