JAI performance

[Jacob]

We build a system that uses JAI (Java Advanced Imaging)
for image processing. It includes advanced image operations
and interaction on large (~10Mb) images.

Project success depends on performance, so the client is prepared
to invest in high-end hardware in order to get the best possible
performance.

So the question is:

Which hardware parameters would actually improve such a program,
and to which extent? (#cores, amount of memory, graphics card
technology etc.). Specific suggestions and experiences would be
quite helpful.

Thanks.

 

[Ramon F Herrera]

We build a system that uses JAI (Java Advanced Imaging)
for image processing. It includes advanced image operations
and interaction on large (~10Mb) images.

Project success depends on performance, so the client is prepared
to invest in high-end hardware in order to get the best possible
performance.

So the question is:

Which hardware parameters would actually improve such a program,
and to which extent? (#cores, amount of memory, graphics card
technology etc.). Specific suggestions and experiences would be
quite helpful.

Thanks.

Jacob:

First off, I hate to be the bearer of bads news. Next, let me tell you
that other than James Gosling, there is no bigger fan of Java than
yours truly. I know I keep on repeating myself but there are some
things that must NOT be written in Java. Heavy duty image processing
and OCR are some of those.

First advice: for that size of images, avoid JAI like the plague.

I wrote an application which handles TIFF files much smaller than
yours. They are monochrome, sampled at 600dpi and their size is about
4 megs. It took me years to finally approach the level of performance
that I am more or less satisfied with, which I achieved rewriting the
whole thing in C++. I researched the most efficient methods for
resizing (do you need resizing and/or resampling? Oh, boy, are you in
trouble), I had to use specialized graphics libraries and code
critical parts in assembly language (*) but the current performance
still keeps me wanting more.

-Ramon

(*) and yet the application will run on Mac, Solaris, Linux and
Windows with a simple recompile.

 

[Jacob]

First off, I hate to be the bearer of bads news. Next, let me tell you
that other than James Gosling, there is no bigger fan of Java than
yours truly. I know I keep on repeating myself but there are some
things that must NOT be written in Java. Heavy duty image processing
and OCR are some of those.

First advice: for that size of images, avoid JAI like the plague.

I wrote an application which handles TIFF files much smaller than
yours. They are monochrome, sampled at 600dpi and their size is about
4 megs. It took me years to finally approach the level of performance
that I am more or less satisfied with, which I achieved rewriting the
whole thing in C++. I researched the most efficient methods for
resizing (do you need resizing and/or resampling? Oh, boy, are you in
trouble), I had to use specialized graphics libraries and code
critical parts in assembly language (*) but the current performance
still keeps me wanting more.

Thanks, this is quite useful.

I might have good reasons to keep this in Java, so in case my
JAI implementation is "good enough", my original question still
applys: Can I speed things by choosing specific hardware?

Then: Are there Java alternatives to JAI that might perform better,
or is the (lack of) image processing performance inherently related
to the existance of the VM?

If I choose an alternative route, say C++/Qt, is there any specific
suggestins regarding open source image libraries that I should look
at?

Thanks.

 

[Ramon F Herrera]

Thanks, this is quite useful.

You are welcome. You will find that people in Java newsgroups are much
more friendly and eager to help than in C++ newsgroups (and I am
talking from the viewpoint of *recipient* of advice and plenty of
useful help). I blame this sad situation on the destruction that
Microsoft made on the C++ language. Fortunately their attempted
destruction of Java was derailed just in time. The victims of this
debacle -a tragedy, really- usually hang out comp.lang.c++. They seem
to have deep war wounds and are very asocial.

Anywho... let's leave politics aside.

I might have good reasons to keep this in Java, so in case my
JAI implementation is "good enough", my original question still
applys: Can I speed things by choosing specific hardware?

I do not have any specifics, but keep in mind that even if you somehow
manage to buy hardware that will be available in 2012, the performance
gains from not using Java will be far superior. I tried to run my
application on hardware with plenty of horsepower, and still was
painfully slow. If your app is ready, just borrow the most powerful PC
you can get, and see it for yourself. That's what I did.

Then: Are there Java alternatives to JAI that might perform better,
or is the (lack of) image processing performance inherently related
to the existence of the VM?

You still have one way of eating your cake and eating it, too. You may
keep all the non-critical (in terms of raw performance) code in Java-
land and use JNI which is a bridge to jump back and forth between
JRE and native code. I went that route and found it confusing and
inelegant, so I decided to take the plunge to a full C++
implementation. This approach works but you will obviously need a
programmer who is very competent in both Java and C++. Additionally
this solution will still be slower than pure C++ because of the bridge
overhead, and the fact that JNI may be inside a critical loop. How
about this: you go this route initially, evaluate performance and
decide whether it is acceptable.

You may also try compiled Java. I have no experience with it, but
logic dictates that it should be much (?) faster.

If I choose an alternative route, say C++/Qt, is there any specific
suggestins regarding open source image libraries that I should look
at?

There are basically 3 GUI toolkits for multi-platform development:

- http://www.gtk.org
- http://www.wxwidgets.org
- http://trolltech.com

The first one didn't give me a warm feeling fuzzy based on the fact
the a *graphical* toolkit didn't even have a decent web page until
now. Perhaps I am being too harsh on the fine folks at GNU, to whom we
all owe so much.

The last one comes with a big caveat, because it is semi commercial
(they were just acquired by Nokia). The free version can only be used
to develop FOSS software!. This is as if anything written in gcc would
have to be open source. This toolkit has been chosen by HP, Google and
Adobe among others.

wxWidgets is by far the one that boasts a larger pool of developers
available, and it is growing like wildfire. You will get plenty of
help here:

http://wxforum.shadonet.com/

They even have a list of talent for hire.

Thanks.

You are quite welcome.

-Ramon

 

[Ramon F Herrera]

wxWidgets is by far the one that boasts a larger pool of developers
available, and it is growing like wildfire. You will get plenty of
help here:

> http://wxforum.shadonet.com/
>
> They even have a list of talent for hire.
>

http://www.wxwidgets.org/support/support.htm

-RFH

 

[Mark Thornton]

Thanks, this is quite useful.

I might have good reasons to keep this in Java, so in case my
JAI implementation is "good enough", my original question still
applys: Can I speed things by choosing specific hardware?

Then: Are there Java alternatives to JAI that might perform better,
or is the (lack of) image processing performance inherently related
to the existance of the VM?

If I choose an alternative route, say C++/Qt, is there any specific
suggestins regarding open source image libraries that I should look
at?

Thanks.

The people in the JAI forum on java.net are usually quite helpful

http://forums.java.net/jive/category.jspa?categoryID=53

Mark Thornton

 

[Ramon F Herrera]

We build a system that uses JAI (Java Advanced Imaging)
for image processing. It includes advanced image operations
and interaction on large (~10Mb) images.

Project success depends on performance, so the client is prepared
to invest in high-end hardware in order to get the best possible
performance.

So the question is:

Which hardware parameters would actually improve such a program,
and to which extent? (#cores, amount of memory, graphics card
technology etc.). Specific suggestions and experiences would be
quite helpful.

Thanks.

Jacob:

You and I are facing the same problem, and perhaps there is room for
cooperation. I have some important tips for you. Could you please drop
me a line to: ramon at patriot dot net?

-Ramon

 

[Roedy Green]

Project success depends on performance, so the client is prepared
to invest in high-end hardware in order to get the best possible
performance.

I have not used this, but it might give you an extra boost:
http://imagero.com/

 

[Lew]

You and I are facing the same problem, and perhaps there is room for
cooperation. I have some important tips for you. Could you please drop
me a line to: ramon at patriot dot net?

Could you please read that note to the entire class?

It is rather rude to promise private knowledge on a public forum, when there
could be many people reading this on tenterhooks looking for the same answers.

We're not asking for proprietary secrets, but sharing hints based on
experience are part of what this Usenet forum is all about.

 

[Ramon F Herrera]

Could you please read that note to the entire class?

I already did.

It is rather rude to promise private knowledge on a public forum, when there
could be many people reading this on tenterhooks looking for the same answers.

The offer is valid to anyone who is struggling to process huge files
on the screen. Just drop me a note to ramon at patriot dot net. It
involves sharing costs on hiring expert personnel who have already
solved that particular problem.

We're not asking for proprietary secrets, but sharing hints based on
experience are part of what this Usenet forum is all about.

I gave a lot more than hints, based in a lot of sweat, blood and
tears.

I just want to make absolutely sure that there is no conflict of
interests between the OP, myself and some information that doesn't
belong to me, and I am not at liberty to disclose (I think).

-RFH