Hi everyone,
Images.jl, a package for processing and visualizing images, has essentially been rewritten from scratch and version 0.6.0 has been tagged. Because this is a major and disruptive release, I suspect a few words are in order.
Images.jl is one of the oldest packages in the Julia ecosystem, and its code-origins predate the existence of both the package manager and Julia 0.1. From the beginning of my own involvement, my main goal was to ensure that it would be useful for both “computer vision” (largely a world of 2d images) and for big-data 3D/4D/5D image analysis. We were partially able to pull that off, but there were some ugly compromises, most notably encoding important information such as the spatial orientation and “meaning” of the axes of an image using an easily lost, desynchronized, or confused dictionary. This may have been the best we could do at the time. However, the Julia language has evolved considerably, and with the release of Julia 0.5 it became apparent that all the pieces were in place for a better approach.
The new Images makes far better use of Julia’s type system. The dictionary is still available for those who want it (through the ImageMetadata package, which is “bundled” with Images itself), but most people should be able to just use “plain arrays,” more specifically a variety of AbstractArray types defined in various packages. Key advances that made this possible include packages such as AxisArrays (which allows one to give names to axes and encode pixel geometry in a type-system-friendly fashion), MappedArrays (which allows one to extend reinterpret-style functionality to arbitrary AbstractArrays), and the existence of the PermutedDimsArray in Base (for lazy-changes of orientation with images too large to handle in memory). Capitalizing on these and other advances in Julia’s treatment of AbstractArrays is the main motivation for the rewrite.
From a user’s perspective, the first thing you’re likely to notice is a whole slew of deprecation warnings and errors, which I know is a major hassle and for which I apologize. (If you have an impending grant deadline, your best bet will probably be to pin the package at an earlier release. I’d also like to thank Tony Kelman for putting significant work into the dependency chains of our package manager to reduce the likelihood of breakage.) One particular pain-point is for Mac users, who for now likely need to rely on ImageMagick (using ImageMagick) to save and load images. I’m hopeful that QuartzImageIO will update to the new version soon. More than a thousand lines of code were devoted to nothing but issuing deprecation warnings (and where necessary, error messages) that attempt to coach you through rewriting your code; I hope these will at least somewhat reduce your pain in making this transition.
While the main emphasis of this rewrite has been on “core” functionality, there are a few goodies to tempt you (e.g., the new mapwindow for applying an arbitrary function over moving windows of an image). The most important reason to upgrade, however, is that I suspect you’ll find the new version to be considerably more robust and well-behaved than the old.
To learn more, the main resources are:
- a new NEWS.md file, which describes the major changes in greater detail
- a completely new set of documentation, now hosted at the JuliaImages umbrella organization
- an upgrading_tips document on handling errors encountered during upgrading to the new version (as you encounter problems, please contribute updates)
- a script to make it easier to deal with the recent name-changes in FixedPointNumbers (i.e., UFixed8->N0f8 etc.)
Finally, Images.jl has been transferred to JuliaImages. Going forward, I hope the main emphasis will be on added functionality, either added to Images.jl itself or implemented in separate packages (Images is evolving into more of an “umbrella” package). I also hope that users contribute “demos” to the JuliaImages documentation, similar to that of other image-processing frameworks. We’d be excited to receive contributions to source code, documentation, or the test suite!
Best,
–Tim Holy
For the user it can be pretty confusing getting the error at the lowest level. So it can make sense to make the type restriction at the interface level. But this discussion is really about duck typing vs making type restriction. So both have pros and cons.