RE: [JAI-IMAGEIO] Loading JPEG2000 with destination image
We have an ImageIO plugin that wraps a Kakadu native implementation.
Unfortunately I can't sell it to you -- not if you offered a million
dollars, my company just doesn't know how to sell software components.
But at least there is hope that it can be done. You obviously need to
build the JNI interfaces for the Kakadu libraries, but they already
exist, you just need to get the license from Dr. Taubman. Academic
researchers get a discount compared to the commercial price.
It should be noted that JAI itself has little or nothing to do with this
discussion -- the J2K plugin is a part of the JAI ImageIO tools, which
does not rely or depend on JAI in any way. My understanding is that the
major reason for putting "JAI" in the name of the tools is that the
software is written and maintained by the same general group of people.
The slow adoption of JPEG2000 is a different thing depending on which
consumer of JPEG2000 you're talking about. my opinion is that there
really isn't much of a need for JPEG2000 in the world wide web at large.
What I mean is that when you go to your bank's website, you don't care
if the images that load are JPEG or JPEG2000 because that application
doesn't require the optimizations JPEG2000 allows.
Now when we start talking about digital photography, that seems like the
place where JPEG2000 could take off. with 10MPixel cameras probably
affordable in the next couple years, JPEG is going to be more and more
inadequate for handling these images well. Many of the digital SLR
cameras use RAW or TIFF as preferable to JPEG now, but JPEG2000 could
probably fit this niche well.
Also, my honest opinion -- and this shouldn't hurt anyone's feelings, in
fact, shouldn't come as a surprise to anyone here -- is that the current
implementation(s) of JPEG2000 decoding in the JAI ImageIO tools are not
adequate to the task of building a robust imaging application designed
for handling large JPEG2000 images. The two plugins (one natively
implemented and one pure java) probably won't ever make the grade for
this purpose, unless they are seriously reengineered.
As I understand it right now (if I'm wrong, please correct me), the two
plugins are unable to really take advantage of PLT markers. I'm talking
a bit out of my league here, but I take this to mean that
in order to read, say, the very last tile of an image, the plugins must
read all the previous tiles too. This is pretty much a showstopper as
far as the usefulness of the plugins, and the reason we ultimately
decided to wrap Kakadu.
OK, those are my opinions on the JPEG2000/JAI ImageIO tools situation.
> -----Original Message-----
> From: Bradford Castalia [mailto:Castalia@PIRL.LPL.Arizona.edu]
> Sent: Thursday, April 13, 2006 8:44 PM
> To: ; ; Nidel, Mike
> Cc: email@example.com
> Subject: Re: [JAI-IMAGEIO] Loading JPEG2000 with destination image
> The reason, I think, that people don't get it when it comes
> to using the capabilities of JPEG2000 is that it is very
> difficult to get. The JPEG2000 standard is relatively complex
> and the data is rather difficult to figure out not to mention
> the uncertainties and confusion associated with the software
> necessary to use the data. Add to this the rather opaque and
> over engineered character of JAI and Image I/O and making
> good use of JPEG2000 is a daunting prospect.
> I've been developing software for over 30 years, with a
> particular emphasis on image file formats and image
> processing operations, and am currently working on the task
> of building a JPEG2000 image data delivery and display
> application. It's rough going. Seeing what's going on in the
> JAI bramble is hard enough; I'm not convinced that the data
> delivery efficiency of JPEG2000 is even being used right by
> the J2K plugin, or that I am using JAI right to achieve the
> efficiency required by the application. Just getting basic
> information out of a JP2 file - such as the number of
> decomposition (resolution) levels - is a struggle with an
> obscured mechanism. But knowing how to work with the software
> to get efficient delivery of only the needed information -
> the primary raison d'etre for JPEG2000 - is a goal I have yet
> to accomplish.
> Because with JPEG2000 image files we're "not in Kansas
> anymore" we need software that will present a reasonably
> clear, if not intuitively obvious, abstraction of the image
> structure and its access methods and include the logic that
> knows how to get the most out of JPEG2000 - intelligent use
> of tiles, precincts, code blocks and decomposition levels
> - while enabling the high level user to work with an image
> rather than a codestream. Not only does the existing JAI
> software not do this, though I know that's its intention,
> it's not clear if it knows what JPEG2000 is about and how to
> work with it.
> But I'm still hacking (;-) away at the brambles with the hope
> of gaining some measure of clarity and effectiveness in
> working with JPEG2000. I would very much like to work with
> others who are interested in taking advantage of the JPEG2000
> potential in the JAI context. A JAI JPEG2000 special interest
> working group seems like it could be a big help. Maybe this
> would lead to people getting it....
> Bradford Castalia Senior
> Systems Analyst
> Planetary Image Research Laboratory University
> of Arizona
> "Build an image in your mind, fit yourself into it."
> Ken Warner wrote:
> I understand what you are saying.
> The mystery is that it really does work. Better looking images in a
> smaller file.
> Why people don't get it -- I dunno.
> Nidel, Mike wrote:
> > If JPEG2000 were really going to be the killer internet imaging
> > standard it was designed to be, it'd be a no-brainer.
> But... I guess
> > not.
> >> -----Original Message-----
> >> From: Ken Warner [mailto:firstname.lastname@example.org] Sent:
> Monday, April
> >> 10, 2006 1:35 PM
> >> To: email@example.com
> >> Subject: Re: [JAI-IMAGEIO] Loading JPEG2000 with destination image
> >> I know... I just like to throw it out there every once in a while
> >> just to keep the idea from totally drying up and blowing away.
> >> Brian Burkhalter wrote:
> >>> I sympathize but I suspect we are pretty much talking about a
> >>> probability zero event here. TIFF isn't even in there yet ....
> >>> Brian
> >>> On Mon, 10 Apr 2006, Ken Warner wrote:
> >>>> If somehow you could convince managment to include
> >> JPEG2000 support
> >>>> --
> >>>> and not just a wrapper around JJ200 -- in J2SE, my one and
> >> only client
> >>>> would be really, really, happy.
> >>> To unsubscribe, e-mail:
> >> firstname.lastname@example.org
> >>> For additional commands, e-mail:
> >>> email@example.com
> >> To unsubscribe, e-mail:
> >> For additional commands, e-mail:
> >> firstname.lastname@example.org
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> > email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com