Closed CounterPillow closed 8 years ago
As @ion1 suggested, I attempted to flip the image so the subtitles are on top, and as it turns out this affects whether the images are corrupted or not.
gm convert 9.png -flip 9_f.png
oxipng -F 9_f.png
Note that no corruption occurs.
EDIT: Cropping from top or bottom also changes the outcome.
Can you test again against f1e6506? I modified much of the filtering code and can't reproduce the issue anymore (I was able to reproduce on 3f42eae).
The images which resulted in corruption before no longer appear to get corrupted.
Great. I'll add a test to make sure the behavior doesn't return, then I'll count this as closed.
I used the following script to run oxipng on a large number of PNG files from my mpv screenshot directory (~650 files), comparing the output of oxipng with the original file using graphicsmagick's compare command. The oxipng version used was 3f42eae01c1469dc88461acc9ad919e35f573d75.
A number of images where the output did not correspond to the input were detected.
(For reasons beyond my comprehension, KonoSuba screenshots seemed to be more likely to get corrupted than others; I'm going to assume oxipng has bad taste in anime.)
As one can see, subtitles, for some reason, often trigger this.
rustc version is
rustc 1.9.0-nightly (998a6720b 2016-03-07)
.