On Wed Sep 02 20:40:05 2015, RKELSCH wrote:
Show quoted text> I simply cannot get Imager to read a string as raw. It sets up an
> Imager object with the right dimensions, but the image inside it is
> blank.
>
> my $img = Imager->new(
> xsize => 100, # dimensions of the image block in string
> ysize => 100,
> channels => 4, # it's a 32 bit image
> type => 'raw',
> data => $image
> );
>
> The object reports a 24 bit (not 32 which is also wrong) 100x100
> image, but nothing is loaded (just black or a solid color). Have
> tried "store channels", "datachannels", "raw_storechannels",
> "raw_datachannels", or instead opening the string as a file and using
> "fh" instead of "data", but it still doesn't work. If I put a "file"
> parameter in there, and remove "type" and load a "PNG" or "JPEG" file,
> it works fine.
>
> I'm not sure if "data" is broken, or "type=raw" is broken.
This looks like a bug in the way Imager::new() differentiates between creating a new blank image and reading an image from a file.
Only the raw type requires the xsize and ysize parameters, but unfortunately Imager::new() uses the existence of those paramaters to decide whether to create a blank image or not.
You can work around this by calling the read() method explicitly:
my $img = Imager->new;
$img->read(
xsize => 100, # dimensions of the image block in string
ysize => 100,
raw_storechannels => 4, # it's a 32 bit image
raw_datachannels => 4, # with 4 channels at the source
raw_interleave => 0, # stored as rgbargba etc
type => 'raw',
data => $image
) or die "Oh no! ", $img->errstr;
You may need to change raw_interleave, depending on how your image is laid out.
I'll look at changing the way Imager::new() distinguishes between the two cases.
The check for xsize/ysize is currently done first because having new() read files was bolted on fairly late in Imager's history, and I pereferred to break new code over breaking old code that was trying to make a new image.
Tony
