Open wx257osn2 opened 2 years ago
Interesting. Thank you for the report! I will check and see if encoder or decoder step is to blame.
So here what I found. Encoders indeed produced a bit different output. And reference qoiconv converted them to a bit different PNGs. But they all were encoding the exactly same pixels.
I've added
${QOICONV_TARGET} /tmp/ref.png /tmp/ref.raw
${QOICONV_TARGET} /tmp/target.png /tmp/target.raw
which saves raw pixel data into files.
Turned out, the output was exactly the same for all listed images except for 3 occurrences.
./qoi_benchmark_suite/images/screenshot_game/Ballerburg.png
./qoi_benchmark_suite/images/screenshot_game/Sega-Mega-Drive-regional-lockout-error.png
./qoi_benchmark_suite/images/screenshot_game/OXO_emulated_portion.png
Those three have Luma8
format and reference qoiconv
decoder converts them to RGBA QOIs.
While rapid-qoi
conversion tool produces RGB QOIs.
I've added temporary change to convert Luma to RGBA and script prints no differences, only two failures to parse source PNGs by image
crate.
If you don't mind, I'll add modified version of your script to the repository to test that all four possible roundtrips produce exactly the same pixel values.
If you don't mind, I'll add modified version of your script to the repository to test that all four possible roundtrips produce exactly the same pixel values.
Sure.
I want to check the result. Could you like to push the raw-data output feature or put the patch for qoiconv/src/main.rs
here?
Yea, I will push changes to allow conversion to raw pixels data and the script.
I wasn't active lately, but I've pushed fix and validation script. The script contains paths to binaries and images directory at the top.
@zakarumych I've confirmed the new commit, but the validate.sh
outputs like below for entire qoi_benchmark_suite
:
../qoi/images/screenshot_game/Htdamg_affinity.png : encode failed by target encoder. skip...
../qoi/images/screenshot_game/Kikinanobot.png : encode failed by target encoder. skip...
../qoi/images/pngimg/viber_PNG2.png : encode by target encoder is not correct
../qoi/images/pngimg/viber_PNG2.png : roundtrip by target encoder-decoder is not correct
Let's ignore the two in screenshot_game
, the result for pngimg/viber_PNG2.png
seems to be not correct.
@zakarumych In my persornal project qoi-benchmark
, rapid-qoi
passes below 3 validations:
stb_image
--> original rawrapid_qoi
encoder --> qoi encoded by rapid-qoi
rapid-qoi
decoder--> raw decoded by rapid-qoi
== original rawrapid_qoi
--reference decoder--> raw decoded by reference implementation == original rawrapid_qoi
--rapid-qoi
decoder--> raw decoded by rapid-qoi
== original rawSo, it seems that the core logic of rapid-qoi
had been fixed at last week.
Like the difference of behaviors between image
crate and stb_image
library you had told me, the problem of viber_PNG2.png
might be in the image reader of rapid-qoi/qoiconv
IMO.
In summary, rapid-qoi/qoiconv
may encode differently than the reference implementation, but the rapid-qoi
as a library had been fixed.
It'd be better if this problem will be fixed, but I don't mind to close this issue since it now works correctly as a library.
(If you will close this issue without fixing above problem, it may be better to write about qoiconv
behavior in the README
. )
According to below script, the encoder of
rapid-qoi
outputs incorrect data with some inputs: