Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oxipng corrupts certain images #29

Closed
CounterPillow opened this issue Mar 10, 2016 · 4 comments
Closed

oxipng corrupts certain images #29

CounterPillow opened this issue Mar 10, 2016 · 4 comments
Labels
I-Critical Issues that are breaking core functionality for a significant portion of users T-Bug Some piece of the software is not working as intended T-Needs Tests

Comments

@CounterPillow
Copy link

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 3f42eae.

#!/usr/bin/env bash
OXI=~/Projekte/oxipng/target/release/oxipng
NUM=0
if [ ! -d "/tmp/oxifaults" ]; then
    mkdir "/tmp/oxifaults"
fi
while IFS= read -rd '' f; do
    rm -f "/tmp/oxitest.png"
    $OXI -F --no-clobber --out "/tmp/oxitest.png" "$f" >> /dev/null 2>&1
    gm compare -maximum-error 0 -metric MSE "$f" "/tmp/oxitest.png" >> /dev/null 2>&1
    if [ $? -ne 0 ]; then
        cp "/tmp/oxitest.png" "/tmp/oxifaults/$NUM-oxi.png"
        echo "$f -> $NUM-oxi.png"
        ((NUM++))
    fi
done < <(find "$1" -type f -iname '*.png' -print0)

A number of images where the output did not correspond to the input were detected.

  1. Original -> Oxipng
  2. Original -> Oxipng
  3. Original -> Oxipng
  4. Original -> Oxipng
  5. Original -> Oxipng
  6. Original -> Oxipng
  7. Original -> Oxipng
  8. Original -> Oxipng
  9. Original -> Oxipng
  10. Original -> Oxipng

(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).

@CounterPillow
Copy link
Author

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.

@shssoichiro shssoichiro added T-Bug Some piece of the software is not working as intended I-Critical Issues that are breaking core functionality for a significant portion of users T-Needs Tests labels Mar 10, 2016
@shssoichiro
Copy link
Owner

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).

@CounterPillow
Copy link
Author

The images which resulted in corruption before no longer appear to get corrupted.

@shssoichiro
Copy link
Owner

Great. I'll add a test to make sure the behavior doesn't return, then I'll count this as closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-Critical Issues that are breaking core functionality for a significant portion of users T-Bug Some piece of the software is not working as intended T-Needs Tests
Projects
None yet
Development

No branches or pull requests

2 participants