http://qs1969.pair.com?node_id=11139985


in reply to Re: How to create and save an image from RGB values
in thread How to create and save an image from RGB values

Thanks, that is what I was looking for, last night: pass Imager a data array or pack'ed binary data. I could not hit that in any doc (with my limited bandwidth). And even now Imager::Draw manages to confuse me more than clear it up.

Is the following equivalent without the functionality of switching the channels (I can create data with any channel arrangement)? Note how I had to change ROSYBROWN to RGBA and that non-transparent seems to be 0xFF!

use strict;
use warnings;
use Imager;

use constant IMAGESIZE => 300;
# RBGA
use constant ROSYBROWN => 0xBC8F8FFF;

my @result = map {              # make us some picture to find when
    ( ROSYBROWN ) x $_,         # examining output, let it be random
    int( rand 0xFFFFFFFF ),     # colour diagonal on uniform BG
    ( ROSYBROWN ) x ( IMAGESIZE - $_ - 1 ),
} 0 .. IMAGESIZE - 1;

my $img = Imager-> new(
    type  => 'raw',
    xsize => IMAGESIZE,
    ysize => IMAGESIZE,
    data  => pack( 'L>*', @result ),
    raw_interleave    => 0,
    raw_datachannels  => 4,
    raw_storechannels => 4,
);
$img->write(file=>'out.png');

[download]

Replies are listed 'Best First'.
Re^3: How to create and save an image from RGB values
by vr (Curate) on Dec 28, 2021 at 13:49 UTC

    Opaque is "1", transparent is "0", that's correct. When 0th (alpha in that case) channel was discarded, its content was irrelevant. Your code is not equivalent, it produces RGBA PNG image (partial random transparency over diagonal). Simply write:

        raw_storechannels => 3,

    [download]

    then Imager will discard 4th (3d, counting from 0) i.e. alpha channel on reading, and then, too, its content would be irrelevant (ROSYBROWN's 4th byte could be any). Then file created will be opaque RGB PNG.

    As an aside, I find Imager documentation excellent, but then all people are different, they say :)

[reply]
[d/l]
      This looks a lot like an application of "Einstein-inspired notation operations" (aka einops) would have helped here. I've been toying with the idea of making a translator from einops notation to PDL slice syntax, but haven't done so yet. I am 100% sure that a pull-request with a PDL::Slices::einops function (with suitable tests, even if incomplete) would be gratefully received :-D

      EDIT The future-design of PDL is being explored on this GitHub issue, including a mention of einops, and anyone with ideas would be extremely welcome to contribute!

[reply]

        When consulting metacpan PDL docs yesterday, found myself continuously stumbling upon word i-am-sure-was-not-there-before. Aha, here. It's not, I believe, anywhere in "changes" or "resolved issues", is it? Please correct me if I'm wrong. Perhaps discussed privately among devs, which of course is up to them to decide, it's not critique from me, just curious to observe how things are changing in general these days. As if "piddle" was an OK for 25 years, and finally last spring fallen off "euphemism treadmill" or something.

        Update: it was announced on mailing list.

[reply]

      got it thanks. it's just I was not able to find in the doc how to do something IMO trivial.

[reply]

In Section Seekers of Perl Wisdom