Remove unused RGBA code, let libpng do the word padding for MacOS.
15 years ago
Attachment #120310 - Flags: review?(cbiesinger) → review+
Comment on attachment 120310 [details] [diff] [review] merge to tip sr=blizzard
Attachment #120310 - Flags: superreview?(blizzard) → superreview+
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Please reopen. The checkin triggered bug #202376 and its duplicates. Glenn
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Red is full-range but appears to be inverted--at least approximately; some of the yellow areas appear darker than they should, but that may be due to gamma correction. Both green and blue are compressed into the upper quarter of the range (191+ and 188+, respectively), and both appear to be folded or wrapped--for example, the chicken should be nearly black, but only its edges are darker, while the middle is as bright as the wall above it. The main kitten is darkest in its medium-level parts, equally light in both its lightest and darkest regions. I don't see anything immediately obvious in the patch that could do that, but as noted in the other bug, the set-filler call will boost the reported number of channels from 3 to 4, which presumably screws up the logic elsewhere. Two other things come to mind: despite the code it replaces, might it be worthwhile to set the filler value to 0xff so that it can be used as alpha (if only to test an alternate code path)? And is decoder->colorLine ever allocated if channels is _not_ greater than 3? (Maybe it doesn't need to be...) I'm looking only at the patch itself, not the full source code, so I could well be missing things. (Was it the intent to remove the RGBA/BGRA code path even for non-Mac builds?)
png_set_filler() wasn't doing what I expected and will cause the interlace buffer to bloat. Closing as WONTFIX.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.