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

New option for adjusting the auto-limit #289

Open
rosell-dk opened this issue May 19, 2021 · 2 comments
Open

New option for adjusting the auto-limit #289

rosell-dk opened this issue May 19, 2021 · 2 comments
Assignees
Milestone

Comments

@rosell-dk
Copy link
Owner

rosell-dk commented May 19, 2021

Take the following case:
We have a low quality jpeg. Lets say the quality is detected as 40.
We have set the "quality" option to 80, meaning we are going for very good quality on the website.
Now, converting with quality 80 is certainly a waste. The visual quality will not be better than the source material, the filesize will however be much greater. This is where the "auto-limit" option comes in. Using that option will make webp-convert use the quality: 40 in this case, rather than 80.

However... How reliable is the detection? And does jpeg quality correspond directly to webp quality?
Being that we in our case are very concerned about visual quality, we might in this case prefer not to go all the way down to q:40. Perhaps we would have preferred q:50 in this case.

However, currently, you can only choose between either going down to detected quality or not. It is in our case either q:40 or q:80.

We should introduce an option that gives users a way to specify a middle way.

The simplest idea would be to add a fixed amount to the detected quality.

Let quality stand for the number specified in the quality option
Let detectedQuality stand for the detected quality
Let adjustment stand for a number specified in a new option

So the simple solution would be:
q = min(quality, detectedQuality + adjustment)

To ensure that the above case would result in q:50, one would set "adjustment" to 10.

One drawback of the simple solution is that it doesn't take the span between detected quality and the quality option into account. Say we have a smaller span. Ie same quality setting (80), but the detected quality is 70. With an adjustment of 10, we end up at 80. We would probably have been willing to go with 75 in that case. In case of a higher adjustment of say 20, the intuition gets stronger that a fixed adjustment isn't what we really want. 20 could make sense if you are very worried about the risk of going too low, but it would mostly make sense when dealing with low quality material. It makes sense to choose a different quality when the source material is 60 than when the source material is 80. This would be destroyed with a fixed adjustment

So, perhaps better with an option that takes the span into account...
q = min(quality, detectedQuality + round((quality - detectedQuality) * adjustment))

To get the desired q:50 in the first example, one would have to set adjustment to 0,25
In the case of a good quality jpeg of 70, we get 73. Pretty good.

For the very concerned, who would prefer 20 in adjustment in the first example, we would have to set adjustment to 0,5. This is a "meet you halfway" solution. First example: quality:80, detectedQuaily:40 => q:60. Second example: quality:80, detectedQuaily:70 => q:75.

The solutions could be combined to allow even more control. However, it seems that the second solution makes a lot of sense. Adding more control would require two options and thus add to the overall complexity without a justified need.

Should we allow negative adjustment. Yeah, why not. Some might have reason to believe that the jpeg quality numbers are higher set than the webp quality. A negative adjustment would adjust for that.

Note that setting adjustment to 1 is the same as not having auto-limit, as the equation reduces to q = quality.

Is this btw intuitive?
We could alternatively define a number that works opposite. We could call it "auto-limit-strength" or "auto-limit-force"
Ie auto-limit-force. 0=No adjustment. 1=Full adjustment.
What is best? auto-limit-adjustment or auto-limit-strength ?

Also, would it be better to accept a percentage? (0-100) rather than (0-1)

And what should be the default?
I'm thinking a minor adjustment of say 10%.
Or - if we go with "auto-limit-strength", a strength of 90%

@rosell-dk rosell-dk added this to the 2.6.0 milestone May 19, 2021
@rosell-dk rosell-dk self-assigned this May 19, 2021
@rosell-dk rosell-dk changed the title New option: auto-limit-adjust New option: auto-limit-adjustment May 20, 2021
@rosell-dk rosell-dk changed the title New option: auto-limit-adjustment New option for adjusting the auto-limit May 20, 2021
@rosell-dk
Copy link
Owner Author

rosell-dk commented May 20, 2021

Added "help wanted". Not for implementation. I'm asking for opinions. Which is most intuitive: "auto-limit-strength" or "auto-limit-adjustment" ? And perhaps there are better ways to deal with this than those I'm proposing?

@HDDen
Copy link

HDDen commented May 25, 2021

Voted for "auto-limit-adjustment"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants