Community
Participate
Working Groups
Currently, you can load PNG images, but not write them out. This is desirable for embedded development since the J2ME Profile MID-P specifies PNG. I'd like a way to use SWT's image loading and conversions to get my graphincs in to PNG format.
We should do this but it's a lot of work to wrote a PNG writer, no? Not for 2.1? Chrix to investigate and advise.
Note to avoid any confusion: MIDP does not support PNG writing either.
I didn't say I wanted to write in MID-P, I use SWT as a tool to do conversions from my other formats on the desktop.
Currently images can only be saved as JPG files. Support for PNG and GIF would be great! See also Bug 38232 and Bug 38186.
*** Bug 88258 has been marked as a duplicate of this bug. ***
I would like to realy have PNG saving funkcionality in eclipse. Current state is horrible, reasons: 1. GIF doesn't support more than 256 colors. 2. JPG has very bad quality, there is no way to adjust it. 3. Conversion from SWT Image to AWT Buffered Image is damn slow.
Hmm, I entered this in 2002. Any chance, since PNG is now a defacto-standard, that this can be revisited?
*** Bug 116067 has been marked as a duplicate of this bug. ***
Created attachment 34001 [details] Patch to add PNG write support. This patch adds support for saving SWT images as PNG files. The patch supports the following PNG color types: Type 2 (RGB triple) at 8 bits with or without SWT.TRANSPARENCY_PIXEL Type 3 (palette) at 8 bits with or without SWT.TRANSPARENCY_ALPHA or SWT.TRANSPARENCY_PIXEL Type 6 (RGB triple with alpha) at 8 bits
Nice clean-looking code, Geoff! I didn't test it yet - just read it quickly. Is it possible to write it using class org.eclipse.swt.internal.image.LZWCodec instead of java.util.zip.Deflater and java.util.zip.DeflaterOutputStream? (possibly not, because LZWCodec uses LZW compression, and I believe PNG uses LZ77 compression, but maybe we could modify the class slightly and reuse it?) Also, can we just do the CRC math, instead of using java.util.zip.CRC32? The reason I ask is that we would prefer not to include the java.util.zip package if possible.
Note that class org.eclipse.swt.internal.image.PngChunk has a method called computeCRC which we can use to do the CRC calculation.
I started to implement this back in November, but I never wrote the compression code (i.e. the IDAT chunk) - I only wrote the "glue" chunks. Then other higher-priority stuff caused me to abandon what I had done. I've dragged it out to compare with your patch, and I think your stuff looks much cleaner. But we really would like to try to avoid the java.util.zip package. (We avoided it for the decoding - I believe it is not available in J2ME). The stuff I did reused the swt internal PngChunk class & subclasses (which is why your code is cleaner... fewer classes <g>). I felt compelled to do it that way because that's what the decoder does (and I didn't write the decoder). The encoding logic that I added is all in PNGFileFormat.unloadIntoByteStream(). I am releasing the code that I wrote, temporarily, so that you can see it. It still throws SWT.ERROR_UNSUPPORTED_FORMAT so that nobody gets hurt <grin>. If you can figure out a way to use LZWCodec and updateAdler to do the compression, then we can use either your code or mine (or a mix) for the rest.
You are correct in that Zip support is not available in CLDC 1.0 or 1.1 and maintaining SWTs low level compatibility is important.
Thanks for the fast feedback. I thought about using the subclasses too, but decided this way was cleaner (and easier). Using PngChunk for CRC should be an easy change, but losing java.util.zip is a bummer. I don't think the LZWCodec will be of much help as PNG uses LZ77, but I'll take a look at it. Thanks for sharing your code; it must be hard to decide which wheel is squeakiest!
Created attachment 36467 [details] Patch to add PNG write support with CLDC compatible zlib support. This is basically the same as the previous patch, except it uses PngChunk for CRC support and it uses a new PngDeflater class for zlib/deflate support. PngDeflater is a simple, straight forward zlib implementation. It uses fixed Huffman codes and a single matching strategy. While portions of PngDeflater are based on Putty's sshzlib.c (which is MIT licensed), any errors or deviations from RFC 1950/1951 are entirely my own fault. Below is a table that shows the difference between using PngDeflater and java.util.zip.Deflater from Java 1.4.2_04 for compression. As you can see, my code is both slower and less effective at compression, but it's not horrible either. I would assume that the built-in zip compression uses dynamic Huffman codes, which may explain some of the compressed size difference. At any rate, this code is a tinkerer's dream, and I've been playing with it for too long, so here it is. file dimensions (pixels) time (milliseconds) size (bytes) zip_small.png 100x89 50 6131 zip_medium.png 787x697 691 53477 zip_large.png 1024x768 1071 334834 test_small.png 100x89 110 7441 test_medium.png 787x697 831 69707 test_large.png 1024x768 1652 396349
Fabulous! Sorry I am just getting back to you today - I was out of the office for March Break. I'll get back to you on this by the end of the day. Carolyn
Very nice, Geoff! Thanks for going back and taking out the java zip dependence. This will work nicely for us now, and I'll probably take the code pretty much verbatim. I might even delete a few of those old PNG loading classes that are not pulling their weight, to make loading and unloading more orthogonal. Because this is more than just a bug fix it needs to be submitted through the "Contribution Questionnaire" process. First, I fill in the following form: http://www.eclipse.org/legal/ContributionQuestionnairePart1-v1.0.php and then someone from the Eclipse Management Organization will look the code over and get back to me before I can commit it. I suspect that this won't happen this week, because a lot of Eclipse folks are away at EclipseCon. I am indicating on the form that I want it in by M6 (March 31). Thank-you very much for your contribution! I will make sure your name is on the SWT contributors page once it goes in.
Form submitted to EMO.
The EMO stuff didn't go through in time to add this feature before the "no more features" milestone (M6), so this will not be able to go into 3.2. We will get it released into the 3.3. stream immediately after 3.2 ships.
Fixed > 20060718. Permission from the EMO was granted, and eclipse 3.2 has shipped. I've released the code to HEAD - it will be in next Tuesday's 3.3 integration build. The ImageAnalyzer example now encodes PNG, and Snippet246.java was added to the SWT snippets page. Thank-you very much for your contribution, Geoff - this is fabulous!
