Sign in to follow this  

PNG filter

This topic is 4520 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm still busy trying to make a png decoder, and while reading the png spec, a question arised. It isn't really clear, but as far as I understand, when using RGB color, the scanlines are stored in the order RGBRGBRGBRGB and not RRRRGGGGBBBB. There's a filter applied to the bytes of scanlines, and it really works on bytes, not on piwels. And that's what made me have this question: because the filter works on bytes, and only uses neighbouring bytes, it seems to me as if you're predicting the G value out of the R and B value next to it, instead of using the G value of the neighbouring pixels. Wouldn't the latter be better for compression, since the G value of two neighbouring pixels is likely to be close to each other?

Share this post


Link to post
Share on other sites
The png spec in sectio 9.2 refers to "the byte corresponding to x in the pixel immediately before the pixel containing x". So when filtering the G byte x, a refers to the G value of the previous pixel, 3 bytes back (in 24 bit color mode).

Share this post


Link to post
Share on other sites

This topic is 4520 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this