Re: More astonishing progress in japi scores

[Sven de Marothy]

Robert Schuster wrote:
>javax.imageio support would be great. I searched for Java libraries
>with friendly licenses and this one seemed to be very interesting:

>JIU - The Java Imaging Utilities -
>http://jiu.sourceforge.net/status.html - GPL

Unfortunately, I don't think we can use GPL code, since Classpath's
license is GPL + exception, which is a more permissable license.
(I.e. you can go GPL+exception-->GPL but not in the other direction.)

But.. on the positive side, there are rumors that Michael Koch has
finished the imageio framework (but not the plugins).

One JPEG-encoder with a compatible license out there is the following:
http://cvs.sourceforge.net/viewcvs.py/jmol/Jmol/src/com/obrador/

>From obrador.com. Unfortunately it has subsequently been relicensed as
closed-source, but that's not a problem as long as we use the version
which was released under a free license.

This code, in turn is apparently based off the Independent JPEG group's
C code, which is the JPEG encoder 'everyone' uses. (libjpeg)

Still, the code could be better, and it'd need a some work to fit it
into the imageio framework. 

Also, if you study that JPEG encoder, a lot of the code is devoted to
doing the RGB->YCC colorspace conversion. That's unnecessary since you
can have awt.color do the same work for you.

I'm currently doing the implementation of java.awt.color.*, and I was
considering doing the JPEG-implementation after that. The inclusion
of the CS_PYCC ColorSpace in java seems to indicate to me that Sun's
implementation uses it for their JPEG encoding/decoding.

Sun's implementation also seems to use a binary ICC-profiles to define
the conversions of it's predefined colorspaces. This is both slower and
less accurate than having routines to do the conversion directly, which
is what I'm implementing. 

So, if you implemented this in java and used java.awt.color, the way I
suspect Sun does it, we could still be both better and faster since they
don't do the colorspace conversion very efficiently.

On the other hand, using a native library like libjpeg would be faster,
and mean less code maintainance for us. The downside is of course the
added dependency and decreased portability.
(although I think libjpeg works on most platforms)

/Sven