Tearing Images.jl appart

[SimonDanisch]

Hi,
Brutal title, I know :D
But I'm working on making image IO more lightweight and then probably unify it under the package ImagIO.
I've started working on an Interface that works like this:

module IO
immutable File{Ending}
path::UTF8String
end
#probably with this as constructor:
file"image.jpg"

read{Ending}(File{Ending}) = #look up and load the correct IO library
end
# then in some other package
module ImageMagick
#implement read
read(File{:jpg}) = "...."
end

I started off by ripping out libmagickwand.
I just wanted to make the point, that It's now way faster, but I actually just measured it and ImageMagick itself seems to be the main culprit in loading times for Images.jl.
Wonder what's going on there. I tried to nail it down with tic(), toc(), but it seems, that this gives me faulty values, as it returns values which must be false (like that include("colortypes.jl") takes 6s and include("libmagickwand.jl") takes 1s and then if you only include "libmagickwand.jl" alone, suddenly this takes 7s).
Anyways, it's still useful, to have all these different functionality differentiated and not all mingled into one package.

By the way, I'm already looking forward to replace all the color arithmetic code by a simple:
type RGB{T} <: FixedSizeVector{T, 3}
:)

Hope this is a direction you can all agree with!
Also it will help to simply switch the loading libraries, which just become a little more relevant as @aaalexandrov just wrapped a nice library (DevIL.jl), which might be more lightweight than imagemagick. Well I don't know, we need to find out ;)
But if they both are separate libraries which implement the same interface, it'll be very easy to switch them out on a higher level.

Best,
Simon

[timholy]

I completely agree with the idea that Images should be modularized. FYI I'm pretty sure that ImageMagick does not account for very much of the load time; a lot of it is surely all the code generation that happens when looping over colortypes. Just put @time statements in front of all the includes in Images.jl, you'll see what I mean.

But the best reason to modularize is because folks have had a lot of trouble with ImageMagick, particularly on OSX. And many people may not even need I/O.

It's not entirely clear what to put in ImagesIO.jl, maybe even that should just be a thin wrapper around several options for I/O. For example,OSXNative.jl might be split out into its own package, for example, although it falls back to the ImageMagick interface when it runs into trouble.

[SimonDanisch]

I was pretty sure as well, but i removed everything but the ~ 200 lines of
imagemagick code... Well julia tricked me before, so further investigations
are needed;)

On Sun, 15 Mar 2015 02:32 Tim Holy [email protected] wrote:

I completely agree with the idea that Images should be modularized. FYI
I'm pretty sure that ImageMagick does not account for very much of the load
time; a lot of it is surely all the code generation that happens when
looping over colortypes. Just put @time statements in front of all the
includes in Images.jl, you'll see what I mean.

But the best reason to modularize is because folks have had a lot of
trouble with ImageMagick, particularly on OSX. And many people may not even
need I/O.

It's not entirely clear what to put in ImagesIO.jl, maybe even that should
just be a thin wrapper around several options for I/O. For
example,OSXNative.jl might be split out into its own package, for example,
although it falls back to the ImageMagick interface when it runs into
trouble.

—
Reply to this email directly or view it on GitHub
#267 (comment).

[timholy]

BTW, at one point I proposed we should start a JuliaImages organization. If you're getting started on this, it seems like a reasonable time to implement that.

[joa-quim]

It may be interesting for you to know that the https://github.com/joa-quim/GMT.jl has reached a working state. It's not finished as among other things it works side-by-side with improvements of the GMT library itself. The interest of this wrapper is that GMT (http://gmt.soest.hawaii.edu/projects/gmt/wiki) uses GDAL (http://www.gdal.org/) to read a lot of formats. So one can now read georeferenced images such as GeoTiff, Jpeg2k, etc..

[timholy]

Good to know. There are so many potential ways to get image data into julia, indeed we shouldn't value ImageMagick above all these others.

Just takes someone to do the work 😄.

[tknopp]

I think this is a very good idea and could myself contribute the analyze format. vtk was prototyped at the mailing list.

However, we need to talk about interfacing. All these formats carry metadata information and I think its important to have:

• low level access to all metadata. The dict approach seems to be promising here
• high level access. This means that the pixelspacing is interpreted the same for all formats.

I have not used the Image type myself but doesn't it provide these two things?

[SimonDanisch]

Yes, I plan to reuse the image type!
That's why there should be three levels of abstraction in the end.
One for files in general in FileIO, which defines the interface and e.g.
the file_str macro. And then the next level is a little bit more concrete,
so for example a package named ImageIO.
In there, the image format will be defined and the different file endings
that are supported by the set of importer/exporters. All the import/export
modules one level deeper should should then implement the read/write
interface, importing and exporting to the higher level, Julia type, which
would be in this case the Image type from Images.jl.
I hope that this will plays out nicely without circular dependencies and
corner cases.

2015-03-15 19:59 GMT+01:00 Tobias Knopp [email protected]:

I think this is a very good idea and could myself contribute the analyze
format. vtk was prototyped at the mailing list.

However, we need to talk about interfacing. All these formats carry
metadata information and I think its important to have:

• low level access to all metadata. The dict approach seems to be
  promising here
• high level access. This means that the pixelspacing is interpreted
  the same for all formats.

I have not used the Image type myself but doesn't it provide these two
things?

—
Reply to this email directly or view it on GitHub
#267 (comment).

[SimonDanisch]

Hi,
the first prototype is working, might have a lot of problems though.
I'm using ColorTypes prematurely and copied a lot of code without really understanding it.
I announced it on the mailing-list and updated the readme.

Hope this can grow into something nice with some crowd effort =)

Best,
Simon

[timholy]

It will be much better to roll ColorTypes into Color. I've got a grant due and am swamped, but I will see what I can do about centralizing these.

[SimonDanisch]

Definitely, that'd be the next big step :) Its a slow process i guess...
I would recommend that ColorTypes stays stand alone, though. The plan behind ColorTypes is to be very lightweight without any functionality, so that it can be integrated into other packages, which just need the types without the rest of the functionality (like the IO packages and GLAbstraction, which don't need the rich functionality of Color.jl). I still need to assert that ColorTypes satisfies all demands. There are still some unresolved questions, like how to treat colors with different field types. Also I fiddled with the type hierarchy a bit, but am not that happy with it yet ;)

[timholy]

Closed by #577