incubator-sanselan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: JPEG Support
Date Thu, 10 Apr 2008 11:28:53 GMT
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