#!/usr/bin/perl
use warnings;
use strict;
use PDL::LiteF;
use PDL::IO::GD;

my $im = PDL::IO::GD->new( { filename => '1Zen16.png' } );

# Grab the PDL of the data:
my $pdl = $im->to_pdl();

print dims $pdl,"\n";

# Allocate some colors:
#
my $black = $im->ColorAllocate( 0,   0,   0 );
my $red   = $im->ColorAllocate( 255, 0,   0 );
my $green = $im->ColorAllocate( 0,   255, 0 );
my $blue  = $im->ColorAllocate( 0,   0,   255 );

# Draw a rectangle:
$im->Rectangle( 10, 10, 290, 290, $red );

# Add some text:
$im->String( gdFontGetLarge(), 20, 20, "Test Large Font!", $green );

# Write the output file:
$im->write_Png( "$0.png" );

##</code><code>##

On Thu, 21 Dec 2006 07:44:43 -0500

>On Wed, 20 Dec 2006 16:47:31 -0600
>Judd Taylor <judd.t@orbitalsystems.com> wrote:
>
>>Also, if you just want to get a piddle out of a PNG, you can just use
>>the non-OO interface for PDL::IO::GD, ie, just use read_png() to read a
>>greyscale image, or use read_true_png() to read an RGB image.
>
>>I wrote PDL::IO::GD, so there's no excuse for the OO interface to not
>>work. Can you provide me with the image you're trying to read, so I can
>>run some tests and see exactly what's going on?


Well just to answer my own question, (I feel dumb now :-) ),
after studying all the tips I was given,
and some investigation, I found the problem was I needed a 
(color Look Up Table) LUT file, for the problematic PseudoClass png.

I used this script to try and compare the values at a point.

#!/usr/bin/perl
use warnings;
use strict;
use PDL::LiteF;
use PDL::IO::GD;

my $file = shift || die "Need a png $!\n";
my $im = PDL::IO::GD->new( { filename => $file } );
my $pdl = $im->to_pdl();

print dims $pdl,"\n";
print "\n";
print  $pdl->at(200,200,0);
print "\t";
print  $pdl->at(200,200,1);
print "\t";
print  $pdl->at(200,200,2);
print "\n";
__END__

with a DirectClass png I would get:
8004003              #800 x 400 x 3
40	93	117      #nice rgb values

which seems to have the right rgb values.

But with a PseudoClass png I would get:
500430                # 500 x 430
Invalid position ..... error msg........
9                         # a lookup table position for rgb

So what kind of value is 9 ?

So I read a bit more about LUTs and the following
solves the problem with reading a PseudoClass png.

#!/usr/bin/perl
use warnings;
use strict;
use PDL::LiteF;
use PDL::IO::GD;

my $file = shift || die "Need a png $!\n";

my $im = PDL::IO::GD->new( { filename => $file } );
my $lut = read_png_lut( $file );
print $lut,"\n";
my $pdl = $im->to_pdl();
write_png_ex($pdl, $lut, "$0.png", 9); 

__END__


Thanks to all.
zentara



>Also, if you just want to get a piddle out of a PNG, you can just use
>the non-OO interface for PDL::IO::GD, ie, just use read_png() to read a
>greyscale image, or use read_true_png() to read an RGB image.

>I wrote PDL::IO::GD, so there's no excuse for the OO interface to not
>work. Can you provide me with the image you're trying to read, so I can
>run some tests and see exactly what's going on?
>
>Thanks,
>	Judd 

Thanks to all of you for the tips, which I will have to study. I've attached
the png file in question.
After mulling it over in my dreams, ( and I may be wrong ) , it appears to me that
the write_true_png_best() wants the color data as r g b , like ff ff ff, instead of
the one dimensional ffffff. So I was trying to find the best way to split the
single dimension into r g b.

Since you are questioning the png file itself, I thought maybe I should try some other
png files, and low-and-behold, they worked fine in the script.

When I looked at the differences, it seems that the working png image
information is similar to:

good.png PNG 82x65 82x65+0+0 DirectClass 13kb

and with the bad png the info is

bad.png PNG 500x430 500x430+0+0 PseudoClass 17c 21kb

So it seems the PseudoClass 17c is the culprit?

Anyways, with all the tips I've been given, I'm miles ahead.
Thanks again to all who replied. 

The pseudo-png file is at  http://zentara.net/zen16.png

zentara

>On Wed, 20 Dec 2006 16:47:31 -0600
>Judd Taylor <judd.t@orbitalsystems.com> wrote:
>
>>Also, if you just want to get a piddle out of a PNG, you can just use
>>the non-OO interface for PDL::IO::GD, ie, just use read_png() to read a
>>greyscale image, or use read_true_png() to read an RGB image.
>
>>I wrote PDL::IO::GD, so there's no excuse for the OO interface to not
>>work. Can you provide me with the image you're trying to read, so I can
>>run some tests and see exactly what's going on?


Well just to answer my own question, (I feel dumb now :-) ),
after studying all the tips I was given,
and some investigation, I found the problem was I needed a 
(color Look Up Table) LUT file, for the problematic PseudoClass png.

I used this script to try and compare the values at a point.

#!/usr/bin/perl
use warnings;
use strict;
use PDL::LiteF;
use PDL::IO::GD;

my $file = shift || die "Need a png $!\n";
my $im = PDL::IO::GD->new( { filename => $file } );
my $pdl = $im->to_pdl();

print dims $pdl,"\n";
print "\n";
print  $pdl->at(200,200,0);
print "\t";
print  $pdl->at(200,200,1);
print "\t";
print  $pdl->at(200,200,2);
print "\n";
__END__

with a DirectClass png I would get:
8004003              #800 x 400 x 3
40	93	117      #nice rgb values

which seems to have the right rgb values.

But with a PseudoClass png I would get:
500430                # 500 x 430
Invalid position ..... error msg........
9                         # a lookup table position for rgb

So what kind of value is 9 ?

So I read a bit more about LUTs and the following
solves the problem with reading a PseudoClass png.

#!/usr/bin/perl
use warnings;
use strict;
use PDL::LiteF;
use PDL::IO::GD;

my $file = shift || die "Need a png $!\n";

my $im = PDL::IO::GD->new( { filename => $file } );
my $lut = read_png_lut( $file );
print $lut,"\n";
my $pdl = $im->to_pdl();
write_png_ex($pdl, $lut, "$0.png", 9); 

__END__


Thanks to all.
zentara


The PNG you have is an indexed palette image. The data is stored as a
single 0-255 value. There is also a lookup table (LUT) stored in the
image that gives a translation between the 0-255 value and the RGB value
that gets displayed. 

If you want to get that image to an RGB pdl, read in the LUT with the
read_png_lut() function:

my $lut = read_png_lut( "zen16.png" );

$lut will be a [3,256] pdl.

Read the image:

my $flat = read_png( "zen16.png" );

Now just apply the LUT to make an RGB image. I think I used to use a
PDL::PP sub for that. Seems useful enough, so I'll probably include
something in PDL::IO::GD like that in the next release.

Until then, I'll let the others on the list come up with something
interesting to do the last step. I'm sure there's some nifty way to
accomplish that with "normal" perl-level PDL.

-Judd



On Thu, 2006-12-21 at 07:44 -0500, zentara wrote:
> On Wed, 20 Dec 2006 16:47:31 -0600
> Judd Taylor <judd.t@orbitalsystems.com> wrote:
> 
> >Also, if you just want to get a piddle out of a PNG, you can just use
> >the non-OO interface for PDL::IO::GD, ie, just use read_png() to read a
> >greyscale image, or use read_true_png() to read an RGB image.
> 
> >I wrote PDL::IO::GD, so there's no excuse for the OO interface to not
> >work. Can you provide me with the image you're trying to read, so I can
> >run some tests and see exactly what's going on?
> >
> >Thanks,
> >	Judd 
> 
> Thanks to all of you for the tips, which I will have to study. I've attached
> the png file in question.
> After mulling it over in my dreams, ( and I may be wrong ) , it appears to me that
> the write_true_png_best() wants the color data as r g b , like ff ff ff, instead of
> the one dimensional ffffff. So I was trying to find the best way to split the
> single dimension into r g b.
> 
> Since you are questioning the png file itself, I thought maybe I should try some other
> png files, and low-and-behold, they worked fine in the script.
> 
> When I looked at the differences, it seems that the working png image
> information is similar to:
> 
> good.png PNG 82x65 82x65+0+0 DirectClass 13kb
> 
> and with the bad png the info is
> 
> bad.png PNG 500x430 500x430+0+0 PseudoClass 17c 21kb
> 
> So it seems the PseudoClass 17c is the culprit?
> 
> Anyways, with all the tips I've been given, I'm miles ahead.
> Thanks again to all who replied. 
> 
> The pseudo-png file is at  http://zentara.net/zen16.png
> 
> zentara
> 

-- 
____________________________

Not sure what's going on with GD - but I use wim and rim, as in:

	$im = rim("foo.png")
	$im *= random(1,1,3)*2;
	wim($im,"bar.png");

It appears that you are reading in a B/W image, which will have
dimensions (X,Y).  You can make it a "color B/W image by expanding
it out with a dummy dimension with
	write_true_png_best($pdl->(:,:,*3))
which will insert a dummy dimension of size 3.  (No additional data
are allocated -- each (X,Y) plane points to the same location in
memory...)

Cheers,
Craig



On Dec 20, 2006, at 2:58 PM, zentara wrote:

> Hi,
> I'm just getting the very basics of PDL, and probably
> will ask some dumb questions.... but thats the way I learn. :-)
>
> This script, reads a png, converts it to piddle ( for some operations
> I would like to try), then I want to print the piddle back out as png.
>
> If I do it like below, I get an error:
> Wrong dimensions (500, 430, 1)! (should be (X,Y,3))
> I have a bad guess commented out, but I can't get
> it right.
> ##################################################
>  #!/usr/bin/perl
> use warnings;
> use strict;
> use PDL::LiteF;
> use PDL::IO::GD;
>
> my $file = shift || die "Need a png $!\n";
>
> my $im = PDL::IO::GD->new( { filename => $file } );
> my $pdl = $im->to_pdl();
>
> #
> # this will give an image but distorted colors
> # $pdl = $pdl * random(1,1,3) * 65535; #color distortion
>
> print dims $pdl,"\n";
> write_true_png_best($pdl, "$0.png", 9);
> __END__
>
>
> ###################################################
>
> So I figure I need to add an extra dimension, but the closest
> I can come is this, (which is bad but at least shows an image).
>
> So what is the best way to promote that XxYx1 image to XxYx3?
>
> Thanks
> zentara
>


Also, if you just want to get a piddle out of a PNG, you can just use
the non-OO interface for PDL::IO::GD, ie, just use read_png() to read a
greyscale image, or use read_true_png() to read an RGB image.

my $pdl = read_png( "filename.png" );

or:

my $pdl = read_true_png( "filename.png" );


Those two functions are _MUCH_ better tested than the new OO interface
in that module. I've been using the non-OO functions for years, but you
might actually be the first person to use the new stuff that was just
added (not kidding). 

I wrote PDL::IO::GD, so there's no excuse for the OO interface to not
work. Can you provide me with the image you're trying to read, so I can
run some tests and see exactly what's going on?

Thanks,
	Judd 



On Wed, 2006-12-20 at 15:15 -0700, Craig DeForest wrote:
> Not sure what's going on with GD - but I use wim and rim, as in:
> 
> 	$im = rim("foo.png")
> 	$im *= random(1,1,3)*2;
> 	wim($im,"bar.png");
> 
> It appears that you are reading in a B/W image, which will have
> dimensions (X,Y).  You can make it a "color B/W image by expanding
> it out with a dummy dimension with
> 	write_true_png_best($pdl->(:,:,*3))
> which will insert a dummy dimension of size 3.  (No additional data
> are allocated -- each (X,Y) plane points to the same location in
> memory...)
> 
> Cheers,
> Craig
> 
> 
> 
> On Dec 20, 2006, at 2:58 PM, zentara wrote:
> 
> > Hi,
> > I'm just getting the very basics of PDL, and probably
> > will ask some dumb questions.... but thats the way I learn. :-)
> >
> > This script, reads a png, converts it to piddle ( for some operations
> > I would like to try), then I want to print the piddle back out as png.
> >
> > If I do it like below, I get an error:
> > Wrong dimensions (500, 430, 1)! (should be (X,Y,3))
> > I have a bad guess commented out, but I can't get
> > it right.
> > ##################################################
> >  #!/usr/bin/perl
> > use warnings;
> > use strict;
> > use PDL::LiteF;
> > use PDL::IO::GD;
> >
> > my $file = shift || die "Need a png $!\n";
> >
> > my $im = PDL::IO::GD->new( { filename => $file } );
> > my $pdl = $im->to_pdl();
> >
> > #
> > # this will give an image but distorted colors
> > # $pdl = $pdl * random(1,1,3) * 65535; #color distortion
> >
> > print dims $pdl,"\n";
> > write_true_png_best($pdl, "$0.png", 9);
> > __END__
> >
> >
> > ###################################################
> >
> > So I figure I need to add an extra dimension, but the closest
> > I can come is this, (which is bad but at least shows an image).
> >
> > So what is the best way to promote that XxYx1 image to XxYx3?
> >
> > Thanks
> > zentara


The PNG you have is an indexed palette image. The data is stored as a
single 0-255 value. There is also a lookup table (LUT) stored in the
image that gives a translation between the 0-255 value and the RGB value
that gets displayed. 

If you want to get that image to an RGB pdl, read in the LUT with the
read_png_lut() function:

my $lut = read_png_lut( "zen16.png" );

$lut will be a [3,256] pdl.

Read the image:

my $flat = read_png( "zen16.png" );

Now just apply the LUT to make an RGB image. I think I used to use a
PDL::PP sub for that. Seems useful enough, so I'll probably include
something in PDL::IO::GD like that in the next release.

Until then, I'll let the others on the list come up with something
interesting to do the last step. I'm sure there's some nifty way to
accomplish that with "normal" perl-level PDL.

-Judd



On Thu, 2006-12-21 at 07:44 -0500, zentara wrote:
> On Wed, 20 Dec 2006 16:47:31 -0600
> Judd Taylor <judd.t@orbitalsystems.com> wrote:
> 
> >Also, if you just want to get a piddle out of a PNG, you can just use
> >the non-OO interface for PDL::IO::GD, ie, just use read_png() to read a
> >greyscale image, or use read_true_png() to read an RGB image.
> 
> >I wrote PDL::IO::GD, so there's no excuse for the OO interface to not
> >work. Can you provide me with the image you're trying to read, so I can
> >run some tests and see exactly what's going on?
> >
> >Thanks,
> >	Judd 
> 
> Thanks to all of you for the tips, which I will have to study. I've attached
> the png file in question.
> After mulling it over in my dreams, ( and I may be wrong ) , it appears to me that
> the write_true_png_best() wants the color data as r g b , like ff ff ff, instead of
> the one dimensional ffffff. So I was trying to find the best way to split the
> single dimension into r g b.
> 
> Since you are questioning the png file itself, I thought maybe I should try some other
> png files, and low-and-behold, they worked fine in the script.
> 
> When I looked at the differences, it seems that the working png image
> information is similar to:
> 
> good.png PNG 82x65 82x65+0+0 DirectClass 13kb
> 
> and with the bad png the info is
> 
> bad.png PNG 500x430 500x430+0+0 PseudoClass 17c 21kb
> 
> So it seems the PseudoClass 17c is the culprit?
> 
> Anyways, with all the tips I've been given, I'm miles ahead.
> Thanks again to all who replied. 
> 
> The pseudo-png file is at  http://zentara.net/zen16.png
>