OK. I agree that '8bit' was the default, so it was redundant, but not wrong, to include it. But declaring $color does not seem to have been the answer for my third or fourth attempt. There does seem to be some sort of dependency between the use of scalar vs. reference on one or both axes. But this still does not clear up the mystery.
In the following, I have kept the startup portion of the code exactly as shown above by Khen1950fx, so I will not repeat it here. May we just concentrate on the getpixel call? First, I have located a portion of the image with distinct values in four adjacent pixels.
for my $x ( 14, 15 )
{
for my $y ( 14, 15 )
{
my @color = $image->getpixel( x => $x, y => $y );
my ( $r, $g, $b, $a ) = $color[0]->rgba();
print " shade( $x, $y ) = $r, $g, $b\n";
}
}
This version produces the output:
Image dimensions: height = 348, width = 349
shade( 14, 14 ) = 255, 255, 255
shade( 14, 15 ) = 221, 221, 221
shade( 15, 14 ) = 170, 170, 170
shade( 15, 15 ) = 51, 51, 51
So far, so good. But now if we replace both axes by referenced lists, we get something I did not expect:
my @color = $image->getpixel( x => [ 14, 15 ], y => [ 14, 15 ] );
for my $clr ( @color )
{
my ( $r, $g, $b, $a ) = $clr->rgba();
print " shade = $r, $g, $b\n";
}
We get, not the full square of scanned pixels, as I expected, but rather just the diagonal.
This would explain why both axes must have identical reference lists. If they differ, the result is undefined.
Image dimensions: height = 348, width = 349
shade = 255, 255, 255
shade = 51, 51, 51
No. That's still not quite it. Actually, the requirement is that both referenced lists do need to be the same length, but the reference is only to pixel pairs, respectively, not the full square (or rectangle), as I assumed it might work.
For example, this works:
my @color = $image->getpixel(
x => [ 13, 15, 17, 17, 20 ],
y => [ 17, 14, 18, 19, 15 ] );
for my $clr ( @color )
{
my ( $r, $g, $b, $a ) = $clr->rgba();
print " shade = $r, $g, $b\n";
}
The output is:
Image dimensions: height = 348, width = 349
shade = 204, 204, 204
shade = 170, 170, 170
shade = 136, 136, 136
shade = 187, 187, 187
shade = 153, 153, 153
And I ran the first code fragment above with the pixel address values such as to display the entire rectangle covered by this last example and the pixel values are exactly those reference pairwise here. In other words, if I had duplicated the pixel addresses for the final printout, I would have:
shade( 13, 17 ) = 204, 204, 204
shade( 15, 14 ) = 170, 170, 170
shade( 17, 18 ) = 136, 136, 136
shade( 17, 19 ) = 187, 187, 187
shade( 20, 15 ) = 153, 153, 153
Any time the pixel reference lists are of unequal length, you get an undefined result. Makes sense, now.
My only complaint then (Tony?), would be that this is not very clear in the 'draw' documentation.