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

V9 Change log and read me #559

Merged
merged 8 commits into from
Oct 10, 2023
Merged

V9 Change log and read me #559

merged 8 commits into from
Oct 10, 2023

Conversation

andrews05
Copy link
Collaborator

@andrews05 andrews05 commented Sep 27, 2023

I haven't updated the actual read me yet, only the template. I'm unsure what we should do about the benchmarks. I don't have a machine with more than 4 primary cores, which I don't think makes a good benchmark.
Do you think we still need them? It currently only shows speed difference vs OptiPNG, though I think compression is equally notable.
We could always drop them for now and add them back some other time.

@AlexTMjugador
Copy link
Collaborator

I'm unsure what we should do about the benchmarks. I don't have a machine with more than 4 primary cores, which I don't think makes a good benchmark. Do you think we still need them? It currently only shows speed difference vs OptiPNG, though I think compression is equally notable.

Since there are many PNG optimizers out there, and the main deciding factors between them are speed and compression, I think it is important to keep the benchmarks up to date, even if only comparing performance with OptiPNG is somewhat limited. I could generate some updated numbers on an Intel Core i7-12700 CPU (20 logical cores, 8 performance cores) if that's okay with you!

@andrews05
Copy link
Collaborator Author

andrews05 commented Sep 28, 2023

Yes, that'd be great! I might see if I can update the script to simplify the way it works with the read me...

Did you have any comments on the change log or read me?

@andrews05
Copy link
Collaborator Author

Right, I've updated the compare script with a couple of key changes:

  1. It operates on the actual README file, so we don't need the separate template.
  2. It no longer requires strip-ansi, so we don't need the node package files.

@@ -41,28 +41,25 @@ Oxipng follows Semantic Versioning.
Oxipng is a command-line utility. Basic usage looks similar to the following:

```
oxipng -o 4 -i 1 --strip safe *.png
oxipng -o 4 --alpha --strip safe *.png

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't suggest --alpha for newbies. It should not be the default. I recently got caught out on some specialist pre-multiplied alpha case, where this caused a breaking change...

Copy link
Collaborator Author

@andrews05 andrews05 Sep 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't worry, it's not the default - this is just an example 🙂
For web or personal use (the majority of use cases), I do think it's a good suggestion. PNG isn't technically supposed to be pre-multiplied (according to the specs) and situations where alpha optimisation is breaking are indeed specialist as you say.

I've changed the wording to say it's an example for web usage.

README.template.md Outdated Show resolved Hide resolved
@AlexTMjugador
Copy link
Collaborator

AlexTMjugador commented Sep 29, 2023

Did you have any comments on the change log or read me?

Other than what @ace-dent suggested, I think the documents are fine 👍

I'll try to do some benchmarks soon, although it's likely I'll be busy these next days.

README.md Outdated
- Strip: Used to remove metadata info from processed images. Used via `--strip [safe,all]`.
Can save a few kilobytes if you don't need the metadata. "Safe" removes only metadata that
will never affect rendering of the image. "All" removes all metadata that is not critical
to the image. You can also pass a comma-separated list of specific metadata chunks to remove.
`-s` can be used as a shorthand for `--strip safe`.

More advanced options can be found by running `oxipng -h`.
More advanced options can be found by running `oxipng -h`, or viewed [here](MANUAL.txt).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this line, but I think the deploy workflow needs to include this file too maybe?

https://github.com/shssoichiro/oxipng/blob/master/.github/workflows/deploy.yml#L57

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I'll mention that in #563.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a note:

  • Comment on parameters being case sensitive.
  • Example of short vs long parameter usage, e.g. -Psavvo6 == --pretend --strip=safe --alpha --verbose --verbose --opt=6.
    This fixes Tolerate lowercase -z parameter #539.

Also suggest pointing user to --help (not -h), for extended help.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ace-dent done

@AlexTMjugador
Copy link
Collaborator

I have just ran the benchmarks on a computer with a Debian sid Linux 6.5.0-2-amd64 kernel, an Intel Core i7-12700 CPU (12C 20T; stock clocks and cooler, but with turbo duration and power limits unlimited by motherboard firmware), and DDR5-5200 RAM in dual channel configuration. I used OptiPNG 0.7.7 as packaged by Debian. I compiled OxiPNG by running cargo build --release on this repository at commit c16519b38b0519988db625913be919d4f0e42f5d, using rustc 1.74.0-nightly (7b4d9e155 2023-09-28). No desktop environment or non-essential background processes were running during the benchmark.

The results were as follows:

Benchmark 1: ./target/release/oxipng -P ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):      59.6 ms ±   7.7 ms    [User: 77.4 ms, System: 3.6 ms]
  Range (min … max):    53.3 ms …  89.9 ms    32 runs
 
Benchmark 2: optipng -simulate ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):     132.4 ms ±   0.8 ms    [User: 132.5 ms, System: 0.6 ms]
  Range (min … max):   131.8 ms … 134.4 ms    22 runs
 
Summary
  ./target/release/oxipng -P ./tests/files/rgb_16_should_be_grayscale_8.png ran
    2.22 ± 0.29 times faster than optipng -simulate ./tests/files/rgb_16_should_be_grayscale_8.png

Benchmark 1: ./target/release/oxipng -o4 -P ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):      88.7 ms ±   4.3 ms    [User: 270.3 ms, System: 11.0 ms]
  Range (min … max):    86.8 ms … 109.4 ms    26 runs
 
Benchmark 2: optipng -o 4 -simulate ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):     444.9 ms ±   0.3 ms    [User: 444.8 ms, System: 0.7 ms]
  Range (min … max):   444.4 ms … 445.6 ms    10 runs
 
Summary
  ./target/release/oxipng -o4 -P ./tests/files/rgb_16_should_be_grayscale_8.png ran
    5.01 ± 0.25 times faster than optipng -o 4 -simulate ./tests/files/rgb_16_should_be_grayscale_8.png

In general, the relative performance of OxiPNG over OptiPNG seems to have remained similar over time.

@andrews05
Copy link
Collaborator Author

Cool, thanks!
The outcome is expected - I've tried to keep the performance curve roughly the same in all the big changes I've made.
Do you want to commit the updated Read Me?

@AlexTMjugador
Copy link
Collaborator

Yeah, I'll push a commit here with the updated readme!

@andrews05
Copy link
Collaborator Author

@AlexTMjugador The compare.sh command should update the Read Me itself, did you not use that?

@AlexTMjugador
Copy link
Collaborator

@AlexTMjugador The compare.sh command should update the Read Me itself, did you not use that?

I used it, but I didn't like how it formatted my CPU name as "12th Gen Intel(R) Core(TM) i7-12700" and did not make distinctions about the number of performance and efficiency cores, so I rewrote that a bit to look nicer in my opinion.

@andrews05
Copy link
Collaborator Author

Ah, fair enough. Do we really need to keep the old benchmarks though?

@AlexTMjugador
Copy link
Collaborator

Do we really need to keep the old benchmarks though?

I think they are useful for historical purposes. There is no harm in keeping them around for now.

@ace-dent
Copy link

ace-dent commented Oct 10, 2023

My 2¢: Old benchmarks have zero value to users of the contemporary release. Even the latest benchmarks are just indicative of performance.
If dev's need the info for some kind of performance analysis(?), it can be seen in git or retested easily.

There is no harm in keeping them ...

Adds more noise for a new user to scan through when first encountering oxipng.

@AlexTMjugador
Copy link
Collaborator

It's a bit more convenient to have the old benchmarks readily available than upon bisecting or checking the Git logs, and they are clearly labeled as old and not shown by default. But I don't have a strong opinion either way, and I don't mind removing them if appropriate.

@andrews05
Copy link
Collaborator Author

Let's do this!

@andrews05 andrews05 merged commit e1db84f into master Oct 10, 2023
13 checks passed
@andrews05 andrews05 deleted the v9 branch October 10, 2023 19:18
Pr0methean pushed a commit to Pr0methean/oxipng that referenced this pull request Dec 1, 2023
Co-authored-by: Alejandro González <me@alegon.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants