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.
