I'd go with option 2 (in the release branch) to get rid of the regression with practically no risk for the release. Performance-wise, nothing is lost compared to 0.92beta.
On 20.12.2006 09:08:38 Simon Pepping wrote: > I would like to know what to do for the release: > 1. Leave as is, a known problem. > 2. Do the quick fix as jeremias suggests: putting the Commons codec > before the ImageIO variant in ImageFactory. > 3. Test Jeremias' patch and apply it. > > We can do the fix in the release branch (to be created) only, in the > interest of an errorless release. > > Simon > > On Tue, Dec 19, 2006 at 11:14:13PM +0100, Jeremias Maerki wrote: > > Actually, this is so simple, I've created a patch. I'm hesitant to apply > > it without much testing with various PNGs for which I have no time right > > now. But maybe one of you can take a look. If it's good JAIImage and > > JimiImage could be similarly patched. > > > > On 19.12.2006 23:01:36 Jeremias Maerki wrote: > > > It turns out the following revision is responsible for the regression: > > > http://svn.apache.org/viewvc?rev=424349&view=rev > > > > > > Putting the Commons codec before the ImageIO variant in ImageFactory is > > > a quick fix for this. I originally switched because of speed reasons but > > > obviously I didn't test PNGs with alpha channel. > > > > > > The reason why Martin's PNG doesn't work with the ImageIOImage class is > > > the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a > > > BITMASK it would work. The same problem exists for JAIImage and > > > JimiImage, BTW. Again, this is something a complete redesign of the > > > image package would have addressed. It's on my higher priority list but > > > I still haven't got to it, yet. If someone wants to try to implement > > > that little code that is missing as a temporary fix, please do. It > > > shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for > > > hints. > > -- > Simon Pepping > home page: http://www.leverkruid.eu Jeremias Maerki
