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.
> 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