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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
