Hello.
On 05/03/07, John Bowler <jbowler acm.org> wrote:
> Executive summary: mal content's code works just fine
on an up-to-date
> gentoo linux with the gs18x8we8 PNG (output from od -t
x1 is "55 aa 55
> aa 55 aa 55 aa" as expected). This is libpng
1.2.15 and zlib 1.2.3
Do you mean 'gs1_8x8.png' here? I didn't distribute a file
with that name.
>
> I also can't see anything wrong with the code.
>
> From: mal content
> >In the case of that program (png-pixels), the raw
binary data is
> >printed to standard out. In cases where I've viewed
the data as
> >noughts and ones or hex, I've piped the raw data
into the
> >standard BSD 'hexdump' utility or a binary viewer.
> >
> >You are correct that 'len' is 1 in the 8x1 example
> >(UNIT_TESTS/DATA/gs1_8x1.png).
>
> Yes, but you gave the 8x8 example gs18x8we8.png, where
'len' is
> actually 8 (bytes). This all seems to be correct, it's
trying to
> write the whole of the byte array corresponding to the
bitmap,
> which is 8x8, so 64 bits, so 8 bytes need to be
written:
There are two possible files (in the referenced .tar.bz2
file,
in UNIT_TESTS/DATA. One is a 1bpp, 8x8 image called
'gs1_8x8.png'
and the other is an 8x1 image of the same bit depth called
'gs1_8x1.png'.
I would expect 'len' to be 8 for the first image and 1 for
the second, as
you said.
$ make
$ ./png-pixels UNIT_TESTS/DATA/gs1_8x8.png | wc -c
8
$ ./png-pixels UNIT_TESTS/DATA/gs1_8x1.png | wc -c
1
However, where I would expect the pixel data to begin with
'10101010':
$ ./png-pixels UNIT_TESTS/DATA/gs1_8x8.png | binview
11010101 10101010 11010101 10101010 11010101 10101010
11010101 10101010
$ ./png-pixels UNIT_TESTS/DATA/gs1_8x1.png | binview
11010101
If there's nothing wrong with the code, then I must be
prodding a libpng
bug somehow.
>
> for (;;) {
> r = write(1, png.pixels + pos, len);
> if (r == 0) break;
> if (r == -1) die_write();
> pos += r;
> len -= r;
> if (!len) break;
> }
>
> (Typically on BSD there will only ever be one 'write'
call made, because
> BSD write doesn't ever return <len - the program
does not set non-blocking
> on fd 1).
Absolutely, but there are a few ways that a cooperating
process could set
non-blocking on this file descriptor.
http://cr.yp.to/un
ix/nonblock.html
>
> The value png.len comes from the code below, in
pngload.c (I believe - i.e.
> assuming I didn't miss somewhere where it gets
changed):
>
> row_len = png_get_rowbytes(png_ptr, info_ptr);
> len = row_len * png->h;
> pix = alloc(len);
> if (!pix) goto ERROR;
>
> png->len = len;
>
> There is one minor problem in there - there are two
possible ways of
> determining the length, in bytes, of a single row from
(struct pngload):
>
> png->len / png->h /* correct */
> (png->w * png->bpp + 7) / 8 /* not necessarily
the same number */
>
> Still, that doesn't matter in this case.
Are you referring to non 8-bit bytes?
>
> I looked at the relevant code and could see nothing
wrong. Like Glenn I
> came
> to the conclusion that the most likely problem is in
the debugging, but
> since my guess is that this comes from a more complex
example where the same
> problem manisfests in some other way maybe not...
>
> Anyway, the only post-write issue I can think of is
that maybe the 'pipe'
> is actually a tty line which only transmits 7 bits,
with no parity and
> one stop bit?
>
Unfortunately not. Just a xterm piping one local process
into another local
process...
cheers,
MC
------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
