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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] >
