incubator-sanselan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Matthew Chen" <charlesmc...@gmail.com>
Subject Re: JPEG Support
Date Sat, 12 Apr 2008 17:11:29 GMT
Hi Carsten,

   I don't know of existing jpeg code we could use.

Charles.


On Thu, Apr 10, 2008 at 1:28 PM, Carsten Ziegeler <cziegeler@apache.org> wrote:
> Ok, thanks for all the answer! So it seems that we *could* do it, but its a
> lot of work. I would really love to have full jpeg support in sanselan - atm
> I don't care about performance.
>
>  Would it be possible to use any existing stuff?
>
>  Carsten
>
>
>
>  Endre StĂžlsvik wrote:
>
> > Charles Matthew Chen wrote:
> >
> > > Hi,
> > >
> > >   My personal feeling about implementing JPEG:
> > >
> > >  * not sure if there is a patent issue.
> > >
> >
> > There aren't any (anymore). Trust me: It'd be heard about by now.
> >
> >
> > >  * a pure-java implementation will always be slower than a native
> > > (c/c++) implementation.
> > >
> >
> > Of course. And much better than a JNI solution, with its inherit dangers
> and noncompatiblity.
> >
> >
> > >
> > >   There might be virtue in adding pure-Java jpeg decode/encode
> > > support to Sanselan, but the case is hard to make.  People use JPEG in
> > > a different way than other formats.  They use it for large collections
> > > of large images.  Performance matters.  Users are going to turn to a
> > > native implementation.  Why rewrite the excellent and mature libjpeg?
> > >
> > >   Its hard to imagine us even doing better (in terms of stability,
> > > maturity and performance) than ImageIO or JAI, which are readily
> > > available.
> > >
> >
> > I don't get this logic at all.
> >
> > What's the actual point of sanselan? You implement TIFF reading etc. Is it
> _only_ types of TIFFs that ImageIO don't read, then? (The JAI stuff is
> really just extra plugins to that now)
> >
> > Having a new, different implementation would be great. Preferably one that
> emphasized the entire "file to BufferedImage" and "BufferedImage to file"
> processes, not as with the "magic" in ImageIO, where you have too little
> understanding of how one end up with the final pixels, or the final bytes.
> All steps should be (able to be) explicit. (Read that as "magic ColorProfile
> apply is bad").
> >
> > JAI does have a real Java implementation of pretty much all of the JPEG
> standards. One more such implementation developed under a really free
> license (Apache) would be great - the same reason for having Harmony, I
> guess?
> >
> > I understand the work-amount argument. I believe I will never understand
> any other argument in this regard.
> >
> > Endre.
> >
> >
>
>
>  --
>
>  Carsten Ziegeler
>  cziegeler@apache.org
>

Mime
View raw message