Skip to main content

RE: [JAI-IMAGEIO] Loading JPEG2000 with destination image

1 reply [Last post]
Anonymous

well for some applications that use applets, a webstart application
would do the job. being bound by the browser's VM plugin is really
painful for anything that requires real image processing (large images
etc). with webstart you can bundle any native libraries you need with
the download. we used to deploy our application as an applet but now
it's primarily a webstart app. 99% of the classes are reused between
the two.

Mike

> -----Original Message-----
> From: Ken Warner [mailto:kwarner@uneedspeed.net]
> Sent: Friday, April 14, 2006 12:16 PM
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Loading JPEG2000 with destination image
>
>
> Finally -- someone with a clear vision of the state of
> JPEG2000 as implemented in ImageIO.
>
> I see nothing I disagree with...
>
> One comment: the wrap for Kakadu's native implementation
> doesn't help JPEG2000 in an applet for the obvious reasons --
> you have to do a separate install of the dll's. What is
> really needed is a simple, straight forward all Java decoder
> for the CODESTREAM part of a JPEG2000 image. That would let
> an applet writer show JPEG2000 encoded images in an applet.
> I think that for most purposes, multiple resolutions and tile
> accessing features of JPEG2000 are overkill for most applets.
>
> IMHO --
>
> Nidel, Mike wrote:
> > 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.
> >
> > Mike
> >
> >
> >>-----Original Message-----
> >>From: Bradford Castalia [mailto:Castalia@PIRL.LPL.Arizona.edu]
> >>Sent: Thursday, April 13, 2006 8:44 PM
> >>To: ; ; Nidel, Mike
> >>Cc: interest@jai-imageio.dev.java.net
> >>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:kwarner@uneedspeed.net] Sent:
> >>
> >>Monday, April
> >>
> >>>>10, 2006 1:35 PM
> >>>>To: interest@jai-imageio.dev.java.net
> >>>>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:
> >>>>
> >>>>
> >>>>interest-unsubscribe@jai-imageio.dev.java.net
> >>>>
> >>>>
> >>>>>For additional commands, e-mail:
> >>>>>interest-help@jai-imageio.dev.java.net
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>------------------------------------------------------------
> ---------
> >>
> >>>>To unsubscribe, e-mail:
> >>
> >>interest-unsubscribe@jai-imageio.dev.java.net
> >>
> >>>>For additional commands, e-mail:
> >>>>interest-help@jai-imageio.dev.java.net
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>
> >>>To unsubscribe, e-mail:
> >>
> >>interest-unsubscribe@jai-imageio.dev.java.net
> >>
> >>>For additional commands, e-mail:
> >>>interest-help@jai-imageio.dev.java.net
> >>>
> >>>
> >>>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> > For additional commands, e-mail:
> > interest-help@jai-imageio.dev.java.net
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Ken Warner

Humm... I should learn more about Webstart. I think I looked at it a couple of years ago and decided that for our client base, the download and install of the JRE was too much to ask of them.

Maybe things will change with Vista when Microsoft finally stops loading it's VM into IE. Yes I know Microsoft doesn't support it's VM anymore but a lot of people still use old versions of IE.

But this is off topic for this list -- a thousand pardons...

Nidel, Mike wrote:
> well for some applications that use applets, a webstart application
> would do the job. being bound by the browser's VM plugin is really
> painful for anything that requires real image processing (large images
> etc). with webstart you can bundle any native libraries you need with
> the download. we used to deploy our application as an applet but now
> it's primarily a webstart app. 99% of the classes are reused between
> the two.
>
> Mike
>
>
>>-----Original Message-----
>>From: Ken Warner [mailto:kwarner@uneedspeed.net]
>>Sent: Friday, April 14, 2006 12:16 PM
>>To: interest@jai-imageio.dev.java.net
>>Subject: Re: [JAI-IMAGEIO] Loading JPEG2000 with destination image
>>
>>
>>Finally -- someone with a clear vision of the state of
>>JPEG2000 as implemented in ImageIO.
>>
>>I see nothing I disagree with...
>>
>>One comment: the wrap for Kakadu's native implementation
>>doesn't help JPEG2000 in an applet for the obvious reasons --
>>you have to do a separate install of the dll's. What is
>>really needed is a simple, straight forward all Java decoder
>>for the CODESTREAM part of a JPEG2000 image. That would let
>>an applet writer show JPEG2000 encoded images in an applet.
>>I think that for most purposes, multiple resolutions and tile
>>accessing features of JPEG2000 are overkill for most applets.
>>
>>IMHO --
>>
>>Nidel, Mike wrote:
>>
>>>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.
>>
>>>Mike
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Bradford Castalia [mailto:Castalia@PIRL.LPL.Arizona.edu]
>>>>Sent: Thursday, April 13, 2006 8:44 PM
>>>>To: kwarner@uneedspeed.net; Brian.Burkhalter@Sun.COM; Nidel, Mike
>>>>Cc: interest@jai-imageio.dev.java.net
>>>>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:kwarner@uneedspeed.net] Sent:
>>>>
>>>>Monday, April
>>>>
>>>>
>>>>>>10, 2006 1:35 PM
>>>>>>To: interest@jai-imageio.dev.java.net
>>>>>>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:
>>>>>>
>>>>>>
>>>>>>interest-unsubscribe@jai-imageio.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>>>For additional commands, e-mail:
>>>>>>>interest-help@jai-imageio.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>------------------------------------------------------------
>>
>>---------
>>
>>>>>>To unsubscribe, e-mail:
>>>>
>>>>interest-unsubscribe@jai-imageio.dev.java.net
>>>>
>>>>
>>>>>>For additional commands, e-mail:
>>>>>>interest-help@jai-imageio.dev.java.net
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>------------------------------------------------------------
>>
>>---------
>>
>>>>>To unsubscribe, e-mail:
>>>>
>>>>interest-unsubscribe@jai-imageio.dev.java.net
>>>>
>>>>
>>>>>For additional commands, e-mail:
>>>>>interest-help@jai-imageio.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail:
>>
>>interest-unsubscribe@jai-imageio.dev.java.net
>>
>>>For additional commands, e-mail:
>>>interest-help@jai-imageio.dev.java.net
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>>For additional commands, e-mail:
>>interest-help@jai-imageio.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net