I noticed something strange, after issuing my $a16_png, then the rpic
command, help vars does not show it. It's there, but help does not show
it. It does, however, when calling it directly. Even undef did not help.
This is in a pdl2 shell.
pdl> my $a16_png;
pdl> help vars
PDL variables in package main::
Name Type Dimension Flow State Mem
----------------------------------------------------------------
$a16 Ushort D [256,255] P 0.12MB
pdl> $a16_png;
pdl> help vars
PDL variables in package main::
Name Type Dimension Flow State Mem
----------------------------------------------------------------
$a16 Ushort D [256,255] P 0.12MB
pdl> $a16_png = rpic('tushort_b16.png')
pdl> help vars
PDL variables in package main::
Name Type Dimension Flow State Mem
----------------------------------------------------------------
$a16 Ushort D [256,255] P 0.12MB
pdl> undef $a16_png
a16_png
pdl> undef $a16_png
pdl> $a16_png = rpic('tushort_b16.png')
pdl> help vars
PDL variables in package main::
Name Type Dimension Flow State Mem
----------------------------------------------------------------
$a16 Ushort D [256,255] P 0.12MB
On 01/17/2012 09:19 PM, Chris Marshall wrote:
Nonetheless, the images look ok which
suggests that the *test checks* are failing
and not necessarily the PNM and PNG
image input and output. Ingo will need
to debug that on his end unless you can
reproduce the problem on your end.
--Chris
On Tue, Jan 17, 2012 at 2:53 PM, David Mertens<[email protected]> wrote:
On Tue, Jan 17, 2012 at 12:49 PM, Chris Marshall<[email protected]>
wrote:
My guess is that the test is checking for equality
rather than approximately.
Could you run the test in the debugger and see
what the value of sum(abs($a16-$a16_png)) is
for the failing test?
What are the data types of the piddles being
compared?
The types are PDL ushorts, so they really should not suffer rounding errors.
Also, my hunch was wrong: shorts appear to be consistently 16 bits, as
discussed here: http://en.cppreference.com/w/cpp/language/types
David
Thanks,
Chris
On Tue, Jan 17, 2012 at 1:29 PM, Ingo Schmid<[email protected]> wrote:
I still get an error, although the images look the same (s.
attachments),
according to diff.
riococo:[tmp]$ perl pic_16bit.t
1..5
ok 1 - use PDL::IO::Pic;
Using the command NONE with the flags -quiet
scaling data to type byte...
using intermediate format PGM
built the command>tbyte_a.pnm to write image
conversion by 'tbyte_a.pnm'
ok 2 - pnm byte image save+restore
Using the command pnmtopng with the flags -quiet
scaling data to type byte...
using intermediate format PGM
built the command |pnmtopng -quiet>tbyte_b.png to write image
conversion by 'pngtopnm -quiet tbyte_b.png |'
ok 3 - png byte image save+restore
Using the command NONE with the flags -quiet
using intermediate format PGM
built the command>tushort_a16.pnm to write image
conversion by 'tushort_a16.pnm'
ok 4 - pnm ushort image save+restore
Using the command pnmtopng with the flags -quiet
using intermediate format PGM
built the command |pnmtopng -quiet>tushort_b16.png to write image
conversion by 'pngtopnm -quiet tushort_b16.png |'
not ok 5 - png ushort image save+restore
# Failed test 'png ushort image save+restore'
# at pic_16bit.t line 66.
# Looks like you failed 1 test of 5.
Best
Ingo
On 01/17/2012 06:57 PM, Chris Marshall wrote:
Please run this modified pic_16bit.t and send the
generated files. I've attached a tar file with the new
test as well as the images output on my platform
(which look ok).
Thanks,
Chris
On Tue, Jan 17, 2012 at 9:25 AM, David
Mertens<[email protected]>
wrote:
Ingo -
Do I understand correctly that you *updated* the PDL ebuild? If so,
you
have
my thanks, as well as the thanks from the rest of the porters! We
should
add
instructions to our wiki for installing PDL on Gentoo. Anything that
makes
PDL easier to install on any platform should be mentioned.
Now, as to your bug, my test passes and looks like the tushort_a16.png
image
that you attached in your follow-up. I have not worked with (or on)
PDL::IO::Pic and I do not have experience with the C library that
backs
it
up, so I cannot be of much help, at least, not with the details that
you
have posted so far. However, this looks like a bona-fide bug, so we
should
probably file a bug report. If you have a sourceforge account, I would
appreciate if you could file a bug here:
http://sourceforge.net/tracker/?func=browse&group_id=612&atid=100612&status=1.
If you do not have a sourceforge account, please reply with the output
of
"perldl -V" so that I can include it in the bug report.
Last point: from the build log, it looks like you have a 64 bit AMD
chip.
I
wonder if this is an issue with 64 bit builds, especially the 64 bit
representation of PDL's short type. But that's just a hunch.
David
--
Sent via my carrier pigeon.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
--
Sent via my carrier pigeon.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
