Bug #32324 for Imager: one or two bugs with scaling, and stripping alpha channels

Tue Jan 15 05:54:28 2008 brianski [...] cpan.org - Ticket created

Subject:

one or two bugs with scaling, and stripping alpha channels

Please see the attached files - run script.pl in a directory with kenya-flagmap.png to generate test[12].png, the latter of which has exposes the bug. it seems as if qtype=>"mixing" leaves the bgcolor non-uniform, which isn't really a problem, because because rgb values don't matter on a 100% transparent pixel. however it does mean the image generated is a bit larger than it needs to be because a uniform bgcolor would compress better... this is a bug, altho by itself, it's a minor one. in any event, when we strip the alpha channel, this has gone from annoyance to bug, because now that information shows thru. I'd argue that this is actually an API bug. it seems that stripping alpha information really needs an extra argument for what to do about 100% transparent pixels. i could see a variety of options: #current behavior $stripped = $img->convert(preset=>"noalpha", bgcolor => "inherit"); #map to blue $stripped = $img->convert(preset=>"noalpha", bgcolor => "0000ff"); inherit should probably be the default, but i can see cases where people are generating images in a web context and want to match the background color of their page, etc. It's arguable as to whether this is one bug or two, but something or another needs-a-fixin' . Cheers...

Subject:

script.pl

#!/usr/bin/perl -w use strict; use warnings; use Imager; my $img = Imager->new(); my $thumb = Imager->new(); $img->open(file => "kenya-flagmap.png") or die $img->errstr; $thumb = $img->scale(xpixels=>150,ypixels=>160,qtype=>"mixing") or die $img->errstr; $thumb->write(file => "test1.png") or die $thumb->errstr; $thumb = $thumb->convert(preset=>"noalpha") or die $thumb->errstr; $thumb->write(file => "test2.png") or die $thumb->errstr;

Subject:

test1.png

Download test1.png
image/png 8.1k

Subject:

kenya-flagmap.png

Download kenya-flagmap.png
image/png 28.9k

Subject:

test2.png

Download test2.png
image/png 5.6k

Tue Jan 15 08:54:40 2008 TONYC [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #32324] one or two bugs with scaling, and stripping alpha channels
Date:	Wed, 16 Jan 2008 00:42:29 +1100
To:	Brian Szymanski via RT <bug-Imager [...] rt.cpan.org>
From:	tonyc [...] cpan.org

Hi Brian, Thanks for your report. On Tue, Jan 15, 2008 at 05:54:32AM -0500, Brian Szymanski via RT wrote: Show quoted text

> Please see the attached files - run script.pl in a directory with > kenya-flagmap.png to generate test[12].png, the latter of which has > exposes the bug. > > it seems as if qtype=>"mixing" leaves the bgcolor non-uniform, which > isn't really a problem, because because rgb values don't matter on a > 100% transparent pixel. however it does mean the image generated is a > bit larger than it needs to be because a uniform bgcolor would compress > better... this is a bug, altho by itself, it's a minor one.

Ok, the alpha channel handing introduced in 0.62 might have caused this. I'll take a look at improving that. Show quoted text

> in any event, when we strip the alpha channel, this has gone from > annoyance to bug, because now that information shows thru. I'd argue > that this is actually an API bug. it seems that stripping alpha > information really needs an extra argument for what to do about 100% > transparent pixels. i could see a variety of options: > #current behavior > $stripped = $img->convert(preset=>"noalpha", bgcolor => "inherit"); > #map to blue > $stripped = $img->convert(preset=>"noalpha", bgcolor => "0000ff"); > > inherit should probably be the default, but i can see cases where people > are generating images in a web context and want to match the background > color of their page, etc. > > It's arguable as to whether this is one bug or two, but something or > another needs-a-fixin' .

This particular case isn't a bug - convert() is a purely mechanical operation that in the case of 'noalpha' simply removes the alpha channel. Internally, every preset converts to a simple matrix operation performed on each pixel. I'll update the documentation to make that clearer and to suggest the mechanism below if you want to compose over some color. The simplest way to compose an image over a given background color in Imager now would be to create a background image of the given color and then rubthrough() to it. Perhaps I should add a method to do a one step "compose over color" operation, Tony

Tue Jan 15 08:54:42 2008 The RT System itself - Status changed from 'new' to 'open'

Tue Jan 15 09:20:55 2008 brianski [...] cpan.org - Correspondence added

From:

ski-cpan [...] allafrica.com

On Tue Jan 15 08:54:40 2008, TONYC wrote: Show quoted text

> Hi Brian, > > Thanks for your report. > > On Tue, Jan 15, 2008 at 05:54:32AM -0500, Brian Szymanski via RT wrote:

> > Please see the attached files - run script.pl in a directory with > > kenya-flagmap.png to generate test[12].png, the latter of which has > > exposes the bug. > > > > it seems as if qtype=>"mixing" leaves the bgcolor non-uniform, which > > isn't really a problem, because because rgb values don't matter on a > > 100% transparent pixel. however it does mean the image generated is a > > bit larger than it needs to be because a uniform bgcolor would compress > > better... this is a bug, altho by itself, it's a minor one.

> > Ok, the alpha channel handing introduced in 0.62 might have caused > this.

Looks like it. I just reverted to 0.60 and got a happy blue background on test2.png when I ran my test script. Show quoted text

> This particular case isn't a bug - convert() is a purely mechanical > operation that in the case of 'noalpha' simply removes the alpha > channel. Internally, every preset converts to a simple matrix > operation performed on each pixel. I'll update the documentation to > make that clearer and to suggest the mechanism below if you want to > compose over some color.

I figured as much, which is why I called it an "API bug" - maybe documentation bug? Show quoted text

> The simplest way to compose an image over a given background color in > Imager now would be to create a background image of the given color > and then rubthrough() to it. > > Perhaps I should add a method to do a one step "compose over color" > operation,

That sounds handy, and is similar enough to what I proposed with RTFS'ing anything that it'd quiet this squeaky wheel ;-) It'd also be nice to be able to do something like this: $rgba_img->write(file => "foo.jpg", transparency_color => $white); Cheers, Brian

Mon Feb 04 23:28:28 2008 TONYC [...] cpan.org - Priority changed from (no value) to '20'

Tue Apr 01 06:11:50 2008 TONYC [...] cpan.org - Taken

Mon Apr 07 05:46:58 2008 TONYC [...] cpan.org - Correspondence added

On Tue Jan 15 09:20:55 2008, BRIANSKI wrote: Show quoted text

> On Tue Jan 15 08:54:40 2008, TONYC wrote:

> > Hi Brian, > > > > Thanks for your report. > > > > On Tue, Jan 15, 2008 at 05:54:32AM -0500, Brian Szymanski via RT wrote:

> > > Please see the attached files - run script.pl in a directory with > > > kenya-flagmap.png to generate test[12].png, the latter of which has > > > exposes the bug. > > > > > > it seems as if qtype=>"mixing" leaves the bgcolor non-uniform, which > > > isn't really a problem, because because rgb values don't matter on a > > > 100% transparent pixel. however it does mean the image generated is a > > > bit larger than it needs to be because a uniform bgcolor would

compress Show quoted text

> > > better... this is a bug, altho by itself, it's a minor one.

> > > > Ok, the alpha channel handing introduced in 0.62 might have caused > > this.

> > Looks like it. I just reverted to 0.60 and got a happy blue background > on test2.png when I ran my test script.

This is fixed in Imager 0.63, the "color" of pixels with zero alpha are now set to 0. Show quoted text

> > The simplest way to compose an image over a given background color in > > Imager now would be to create a background image of the given color > > and then rubthrough() to it. > > > > Perhaps I should add a method to do a one step "compose over color" > > operation,

> > That sounds handy, and is similar enough to what I proposed with > RTFS'ing anything that it'd quiet this squeaky wheel ;-) > > It'd also be nice to be able to do something like this: > $rgba_img->write(file => "foo.jpg", transparency_color => $white);

With Imager 0.63, you can now supply a background color when writing jpeg/pnm/bmp images and the image will be written to the file as if composited against that background. If no i_background is set it is composited against a black background. Sorry for the delay on this. Tony

Mon Apr 07 05:47:06 2008 TONYC [...] cpan.org - Status changed from 'open' to 'resolved'