Java equivalent to Python's Imaging Library (PIL)
Mark Engelberg
Thanks.
Korny Sietsma
rewrite - there's jmagick but it sounds like a pain to get it working
on osx, and there's a library that wraps imagemagick command-line, but
something native that supports:
- 48 bits-per-pixel images
- colour profiles
- digital camera raw files (I can do this from the command line,
again, but prefer not)
... would be good. Java Advanced Imaging seems to do some of this,
but it's ugly, and the documentation seems uglier...
- Korny
Kornelis Sietsma korny at my surname dot com
kornys on gmail, twitter, facebook, etc.
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"
Albert Cardona
> Can anyone point me to a PIL-like library that will work from Clojure?
Hi Mark,
We use clojure to handle the java-only ImageJ application and library.
It's not what you'd call an industrial-strength library, but rather a
dedicated practical application for scientific image processing.
All file formats on Earth are supported. If you format is not listed,
just use File - Import - Raw... and specify header size, data format,
etc. to decode it into an image.
While ImageJ ij.jar can be used independently, we wrapped it with
clojure and many other libs in a package named Fiji, available at
There are numerous clojure examples here:
http://pacific.mpi-cbg.de/wiki/index.php/Clojure_Scripting
Upon download, you may want to replace the clojure.jar with a newer one,
in the jars/ folder.
The simple way to run the application is to invoke:
./fiji
But it can run clojure scripts too:
./fiji path/to/program.clj
And even launch a REPL:
./fiji --main-class clojure.lang.Repl
Extra options are given as:
./fiji -cp /some/extra/file.jar:/some/other.jar -Xincgc
path/to/program.clj
See ./fiji --help for more options.
Albert
--
Albert Cardona
http://albert.rierol.net
Michael Wood
On Thu, Mar 12, 2009 at 2:01 PM, Albert Cardona <sapr...@gmail.com> wrote:
>
> Mark Engelberg wrote:
>> Can anyone point me to a PIL-like library that will work from Clojure?
>
>
> Hi Mark,
>
> We use clojure to handle the java-only ImageJ application and library.
>
> It's not what you'd call an industrial-strength library, but rather a
> dedicated practical application for scientific image processing.
>
> All file formats on Earth are supported. If you format is not listed,
> just use File - Import - Raw... and specify header size, data format,
> etc. to decode it into an image.
>
> While ImageJ ij.jar can be used independently, we wrapped it with
> clojure and many other libs in a package named Fiji, available at
>
> http://pacific.mpi-cbg.de
>
> There are numerous clojure examples here:
>
> http://pacific.mpi-cbg.de/wiki/index.php/Clojure_Scripting
This looks really interesting. One thing I noticed, though, is that
the page links to "clojure.sourceforge.net" as the Clojure web site.
Although that does redirect to the correct place (clojure.org) it
could give people the false impression that Clojure is still hosted on
Sourceforge. (Yes, I know it's a Wiki, but it's easier to reply to
your message than to create yet another account on yet another web
site just to make one minor change.)
By the way, I've never used ImageJ, but would be interested to know
why you say it is "not what you'd call an industrial-strength
library".
--
Michael Wood <esio...@gmail.com>
Albert Cardona
Hi Michael,
> This looks really interesting. One thing I noticed, though, is that
> the page links to "clojure.sourceforge.net" as the Clojure web site.
> Although that does redirect to the correct place (clojure.org) it
> could give people the false impression that Clojure is still hosted on
> Sourceforge. (Yes, I know it's a Wiki, but it's easier to reply to
> your message than to create yet another account on yet another web
> site just to make one minor change.)
Thanks, I've updated the links.
> By the way, I've never used ImageJ, but would be interested to know
> why you say it is "not what you'd call an industrial-strength
> library".
Because ImageJ's ij.jar became a library long after being just an
application. There is no concept of MVC, and thus GUI classes are mixed
with processing and controller constructs. What's worse, most plugins
operate on the concept of the active image, which originally was the
image contained on the selected image window--but any image on which one
calls ".show()" will become the active image, which can happen anytime
... from any plugin, and different for each.
Also, the sin of keeping unsafe internal state is committed in numerous
places, particularly affecting the dialog's default values (static
fields), which are then changed by subsequent instatiations of the
dialog. The static fields are used directly in the execution of the
plugin processes, resulting in very unsafe multithreading.
All the above though doesn't affect the core data structures, neither
the I/O (since about a year from now or so).
In addition, all image processing is basically 2D: one can't resize an
image 3D volume. There are stacks of 2D images, very easy to use, but
they are not true 3D volumes neither are they processed as such.
There's also support for 4D (3D+time) with hyperstacks, again an ad-hoc
structure that is simply a long array of 2D images.
Here are a few descriptions on the core ImageJ datastructures, at high,
mid and low level of pixel operations:
http://albert.rierol.net/imagej_programming_tutorials.html#ImageJ%20programming%20basics
Some threading safety techniques are explained here:
There's a very active ImageJ malining list on the main ImageJ website,
which answers to all questions:
Hope that helped.
Michael Wood
On Thu, Mar 12, 2009 at 4:06 PM, Albert Cardona <sapr...@gmail.com> wrote:
>
>
> Hi Michael,
[...]
>
> Because ImageJ's ij.jar became a library long after being just an
> application. There is no concept of MVC, and thus GUI classes are mixed
> with processing and controller constructs. What's worse, most plugins
> operate on the concept of the active image, which originally was the
> image contained on the selected image window--but any image on which one
> calls ".show()" will become the active image, which can happen anytime
> ... from any plugin, and different for each.
[...]
> Hope that helped.
Yes, thanks :)
--
Michael Wood <esio...@gmail.com>
Michael Wood
On Thu, Mar 12, 2009 at 4:06 PM, Albert Cardona <sapr...@gmail.com> wrote:
>
>
> Hi Michael,
[...]
>
> Because ImageJ's ij.jar became a library long after being just an
> application. There is no concept of MVC, and thus GUI classes are mixed
> with processing and controller constructs. What's worse, most plugins
> operate on the concept of the active image, which originally was the
> image contained on the selected image window--but any image on which one
> calls ".show()" will become the active image, which can happen anytime
> ... from any plugin, and different for each.