|
|
| Re: Oddity when handling < 8bpp
images. |
  United States |
2007-03-02 06:13:18 |
At 04:22 AM 3/2/2007 +0000, mal content wrote:
>Hello.
>
>I think there's something strange going on with libpng
on my system,
>specifically with the handling of low bit-depth images.
Now correct
>me if I'm wrong, but the following 8x8 1 bit
checkerboard image:
>
>h
ttp://img98.imageshack.us/img98/7632/gs18x8we8.png
>
>...should, when decompressed to raw pixel data, show the
following
>bit pattern when viewed in a binary editor:
>
>10101010 10101010 10101010 10101010 10101010 10101010
10101010 10101010
>
>However, the first byte returned from png_read_row()
doesn't look
>like this at all, and the resulting bit pattern for the
image turns
>out like this:
>
>11010101 10101010 11010101 10101010 11010101 10101010
11010101 10101010
>
>One bit appears to be duplicated in places.
>
Your PNG looks OK to me:
$ wget h
ttp://img98.imageshack.us/img98/7632/gs18x8we8.png
--05:56:52-- h
ttp://img98.imageshack.us/img98/7632/gs18x8we8.png
=> `gs18x8we8.png'
$ gm convert gs18wx8we8.png -compress none gs18x8we8.pbm
$ cat gs18x8we8.pbm
P1
8 8
1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1
0 1 1 0 1 0
1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1
$ pngcheck -v -v gs18x8we8.png
File: gs18x8we8.png (71 bytes)
chunk IHDR at offset 0x0000c, length 13
8 x 8 image, 1-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 14
zlib: deflated, 256-byte window, maximum compression
zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4
paeth):
0 0 0 0 0 0 0 0 (8 out of 8)
chunk IEND at offset 0x0003f, length 0
No errors detected in gs18x8we8.png (3 chunks, -787.5%
compression).
I thought zlib would not allow a 256-byte window, so maybe
there is
something wrong there, if you are using an older zlib to do
your
decompression. I'm using zlib-1.2.3.
Glenn
------------------------------------------------------------
-------------
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-02 11:23:30 |
On 02/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
> Your PNG looks OK to me:
> $ wget h
ttp://img98.imageshack.us/img98/7632/gs18x8we8.png
> --05:56:52-- h
ttp://img98.imageshack.us/img98/7632/gs18x8we8.png
> => `gs18x8we8.png'
> $ gm convert gs18wx8we8.png -compress none
gs18x8we8.pbm
> $ cat gs18x8we8.pbm
> P1
> 8 8
> 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1
0 1 0 1 1 0 1 0
> 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0
1
See that's what I don't understand. Surely a 1-bit
checkerboard pattern
should be a stream of alternating 1 and 0, yet in the pixel
data above,
there are segments of '11' and '00'. Is this correct
behaviour?
> I thought zlib would not allow a 256-byte window, so
maybe there is
> something wrong there, if you are using an older zlib
to do your
> decompression. I'm using zlib-1.2.3.
I'm using libpng 1.2.14 and the FreeBSD 6.2 system libz,
which I believe
is also 1.2.3.
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |
  United States |
2007-03-02 12:12:34 |
At 05:23 PM 3/2/2007 +0000, mal content wrote:
>On 02/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
>> Your PNG looks OK to me:
>> [...]
>> P1
>> 8 8
>> 1 0 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1
0 1 0 1 0 1 1 0 1 0
>> 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 1 0 1 0 1
0 1
>
>See that's what I don't understand. Surely a 1-bit
checkerboard pattern
>should be a stream of alternating 1 and 0, yet in the
pixel data above,
>there are segments of '11' and '00'. Is this correct
behaviour?
Look at it again, with linefeed after each line
P1
8 8
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1
The color of the first pixel in each line is the same as the
last
pixel in the previous line. If all lines were the same then
you'd
have vertical stripes instead of a checkerboard pattern.
D'oh?
Glenn
------------------------------------------------------------
-------------
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-02 12:18:00 |
On 02/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
>
> The color of the first pixel in each line is the same
as the last
> pixel in the previous line. If all lines were the same
then you'd
> have vertical stripes instead of a checkerboard
pattern.
>
> D'oh?
D'oh!
I still don't know why I'm seeing the particular bit pattern
on my
system though:
11010101
That's the first byte of the PNG, and the first row of the
checkerboard.
Would it be easier if I just posted my code?
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-02 13:27:46 |
On 02/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
> At 06:18 PM 3/2/2007 +0000, mal content wrote:
> >Would it be easier if I just posted my code?
>
> You might as well. We can't do much more without it.
> About the zlib version: you can print the version
number
> (ZLIB_VERSION in zlib.h), just to be sure.
>
pngload.c is the file in question:
http://d.turboupload.com/d/1574822/pngloa
d_20070302-192418.tar.bz2.html
Specifically, lines 173-187.
ZLIB_VERSION is 1.2.3.
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-04 22:16:06 |
On 02/03/07, mal content <artifact.one googlemail.com> wrote:
> pngload.c is the file in question:
>
> http://d.turboupload.com/d/1574822/pngloa
d_20070302-192418.tar.bz2.html
>
> Specifically, lines 173-187.
>
> ZLIB_VERSION is 1.2.3.
>
Nobody had any luck with this?
With the simplest of 1bpp images, I get incorrect pixel
data.
A simple 8x1 image, of alternating black and white pixels
results in
the following
bit pattern:
11010101
When it should result in the following:
10101010
Note that I'm not using png_set_expand().
Is this possibly a bug? Due to the fact that every bit of
source for any program
on my system I've examined uses png_set_expand() and mine
doesn't...
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-04 22:33:53 |
On 05/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
> At 04:16 AM 3/5/2007 +0000, mal content wrote:
> >On 02/03/07, mal content <artifact.one googlemail.com> wrote:
> >> pngload.c is the file in question:
> >>
> >> http://d.turboupload.com/d/1574822/pngloa
d_20070302-192418.tar.bz2.html
> >>
> >> Specifically, lines 173-187.
> >>
> >> ZLIB_VERSION is 1.2.3.
> >>
> >
> >Nobody had any luck with this?
>
> I get an ad for hot chicks, wait for the countdown, hit
"download", and
> nothing happens. I guess turboload doesn't like
firefox. I didn't
> pursue the problem.
Hmm. I use it with firefox on BSD all the time. I'll try and
find somewhere
else to host the file.
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-04 22:52:05 |
On 05/03/07, mal content <artifact.one googlemail.com> wrote:
> > >Nobody had any luck with this?
> >
> > I get an ad for hot chicks, wait for the
countdown, hit "download", and
> > nothing happens. I guess turboload doesn't like
firefox. I didn't
> > pursue the problem.
>
> Hmm. I use it with firefox on BSD all the time. I'll
try and find somewhere
> else to host the file.
Here's another copy, hosted privately:
http://waste.corolla.ath.cx/pngload_20070305-044559.t
ar.bz2
http://waste.corolla.ath.cx/pngload_20070305-0445
59.tar.bz2.md5
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-04 22:54:07 |
On 05/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
> At 04:33 AM 3/5/2007 +0000, mal content wrote:
> >Hmm. I use it with firefox on BSD all the time.
I'll try and find somewhere
> >else to host the file.
>
> You can upload files to the libpng bug tracker at
SourceForge. Open a bug
> report first, then upload your file to it.
Ah, ok. I'll do that if/when we've established that it
really is a bug
and not just
some stupidity on my part.
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|
| Re: Oddity when handling < 8bpp
images. |

|
2007-03-04 23:19:34 |
On 05/03/07, Glenn Randers-Pehrson <glennrp comcast.net> wrote:
> At 04:54 AM 3/5/2007 +0000, mal content wrote:
> >else to host the file.
>
> OK, got it. It's too much for me to assimilate right
now though.
> You may be on the right track about png_set_expand(),
since you are
> trying to read 1-bit pixels.
>
Note that I don't actually want to use png_set_expand() if
it can be avoided.
My ultimate intention is to process the 1bpp pixel data and
pass it to OpenGL
using GL_BITMAP (which requires 1bpp data).
For now I'm assuming that there's some bug in the way that
< 8bpp data is
either written or read and that png_set_expand() negates the
bug somehow,
so it doesn't appear to occur in other software.
I could be totally wrong, of course.
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-implement lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement
|
|