* [9fans] bug in topng(1)
@ 2012-12-24 12:27 yaroslav
0 siblings, 0 replies; 6+ messages in thread
From: yaroslav @ 2012-12-24 12:27 UTC (permalink / raw)
To: 9fans
There's a bug in topng(1) which under certain circumstances may result in
broken output image. When such an image then is fed to png(1)
diagnostics like the following are produced:
term% png /tmp/1.png
png: unknown filtering scheme 49
(The filtering scheme number may differ.)
This happens when at the beginning of an input line (z->x == 0) there
are only room for exactly one pixel in output buffer (b+pixwids == e),
at /sys/src/cmd/jpg/writepng.c:/^zread/+/while/.
Since every scan line should start with a filter algorithm ID it
consumes a byte in the buffer, leaving no room for the pixel. The
"pixels" variable turns zero, no pixels are emitted, yet the alg byte
slips out. During next run of zread() with empty buffer, the alg byte
is emitted again, causing permanent skew of output bytes.
The proposed fix is to modify the loop condition so the loop won't
proceed if there are not enough room for at least one pixel plus a
byte for the filter alg ID.
Submitted /n/sources/patch/topng-extrabyte/.
- yk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in topng(1)
2012-12-25 1:49 ` cinap_lenrek
@ 2012-12-25 13:39 ` erik quanstrom
0 siblings, 0 replies; 6+ messages in thread
From: erik quanstrom @ 2012-12-25 13:39 UTC (permalink / raw)
To: 9fans
patch submitted,
/n/sources/patch/pngfencepost
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in topng(1)
2012-12-24 20:01 ` erik quanstrom
@ 2012-12-25 1:49 ` cinap_lenrek
2012-12-25 13:39 ` erik quanstrom
0 siblings, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2012-12-25 1:49 UTC (permalink / raw)
To: 9fans
correct. the Bread() is basically sound. must'v been drunk when coming
up with it.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in topng(1)
2012-12-24 17:45 ` cinap_lenrek
@ 2012-12-24 20:01 ` erik quanstrom
2012-12-25 1:49 ` cinap_lenrek
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2012-12-24 20:01 UTC (permalink / raw)
To: 9fans
On Mon Dec 24 12:46:29 EST 2012, cinap_lenrek@gmx.de wrote:
> fixed in 9front, its a off by one in the image size calculation.
can you explain what the difference between Bread and Breadn is?
it looks to me that they have they both return count on a full read,
nread on a partial read after having gotten a return of 0/-1 from a
read but with some bytes available, and 0/-1 if there are no bytes
available and the (first) read returned 0/-1.
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in topng(1)
2012-12-24 14:07 Erik Quanstrom
@ 2012-12-24 17:45 ` cinap_lenrek
2012-12-24 20:01 ` erik quanstrom
0 siblings, 1 reply; 6+ messages in thread
From: cinap_lenrek @ 2012-12-24 17:45 UTC (permalink / raw)
To: 9fans
fixed in 9front, its a off by one in the image size calculation.
--
cinap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in topng(1)
@ 2012-12-24 14:07 Erik Quanstrom
2012-12-24 17:45 ` cinap_lenrek
0 siblings, 1 reply; 6+ messages in thread
From: Erik Quanstrom @ 2012-12-24 14:07 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
yaroslav <yarikos@gmail.com> wrote:
>There's a bug in topng(1) which under certain circumstances may result in
>broken output image. When such an image then is fed to png(1)
>diagnostics like the following are produced:
>
> term% png /tmp/1.png
> png: unknown filtering scheme 49
>
>(The filtering scheme number may differ.)
>
>This happens when at the beginning of an input line (z->x == 0) there
>are only room for exactly one pixel in output buffer (b+pixwids == e),
>at /sys/src/cmd/jpg/writepng.c:/^zread/+/while/.
>
>Since every scan line should start with a filter algorithm ID it
>consumes a byte in the buffer, leaving no room for the pixel. The
>"pixels" variable turns zero, no pixels are emitted, yet the alg byte
>slips out. During next run of zread() with empty buffer, the alg byte
>is emitted again, causing permanent skew of output bytes.
>
>The proposed fix is to modify the loop condition so the loop won't
>proceed if there are not enough room for at least one pixel plus a
>byte for the filter alg ID.
>
>Submitted /n/sources/patch/topng-extrabyte/.
>
>- yk
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-12-25 13:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-24 12:27 [9fans] bug in topng(1) yaroslav
2012-12-24 14:07 Erik Quanstrom
2012-12-24 17:45 ` cinap_lenrek
2012-12-24 20:01 ` erik quanstrom
2012-12-25 1:49 ` cinap_lenrek
2012-12-25 13:39 ` erik quanstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).