Skip Menu |
 

This queue is for tickets about the Imager CPAN distribution.

Report information
The Basics
Id: 32324
Status: resolved
Priority: 20/
Queue: Imager

People
Owner: TONYC [...] cpan.org
Requestors: brianski [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.62
Fixed in: (no value)



Subject: one or two bugs with scaling, and stripping alpha channels
Download (untitled) / with headers
text/plain 1.2k
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
Download script.pl
text/x-perl 442b
#!/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
test1.png
Subject: kenya-flagmap.png
Download kenya-flagmap.png
image/png 28.9k
kenya-flagmap.png
Subject: test2.png
Download test2.png
image/png 5.6k
test2.png
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
From: ski-cpan [...] allafrica.com
Download (untitled) / with headers
text/plain 1.8k
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
Download (untitled) / with headers
text/plain 1.8k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.