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

Feature request: set scale_weights in CLI #121

Open
homm opened this issue May 15, 2022 · 7 comments
Open

Feature request: set scale_weights in CLI #121

homm opened this issue May 15, 2022 · 7 comments

Comments

@homm
Copy link

homm commented May 15, 2022

In my understanding this is a key parameter which should not be hardcoded, since it mostly depends on how the image is showed to the user. At least I believe scale_weights should be different for 2x and 1x images.

The possible syntax:

dssim --weights 0.028,0.197,0.322,0.298,0.155 file.png modified1.png

As a bonus, this unleashes the easy way to turn multiple-resolution comparison to single-resolution just by defining --weights 1.

By the way I'm wondering how the current DEFAULT_WEIGHTS was chosen. There is a comment in the code: "inspired by the IW-SSIM, but details of the algorithm and weights are different" but without details.

@kornelski
Copy link
Owner

These hyperparameters are dependent on viewing conditions indeed. They've been tuned (or overfitted 😄) for the TID2013 dataset.

It would be nice to have something for 2x images. Perhaps just shifting them by one would be okay? But without a dataset to validate this, it'd be only guessing.

I'd rather not expose that in CLI as raw numbers, because if I don't have a way to set better values, I don't expect users to be able to either.

@homm
Copy link
Author

homm commented May 17, 2022

Perhaps just shifting them by one would be okay?

Hmm, this will mean that the best 2x image is a good quality 1x image scale up bicubically :-)

To be honest, I'm surprised that the first layer is 7 times less significant than second. This is the first thing I'd like to experiment with if this functionality will be available.

@kornelski
Copy link
Owner

You can experiment with it by recompiling the program. Compiling Rust is a bit slow, but not difficult.

@igv
Copy link
Contributor

igv commented May 19, 2022

To be honest, I'm surprised that the first layer is 7 times less significant than second.

Agree. I've experimented with only 2 scales (WEIGHTS = [0.2, 0.8]) and it shows reasonable results.

@kornelski
Copy link
Owner

How did you verify "reasonable"? The weights affect the TID benchmark by about 3%, so it's not something you can eyeball.

@igv
Copy link
Contributor

igv commented May 19, 2022

I've used images from this comparison and compared results to VIFp (I think now I prefer this metric over MS-SSIM).

@homm
Copy link
Author

homm commented May 31, 2022

I'm sure you've already seen this thread, but I'd like to add it here for others who will read the issue.

There's no excuse for using 1x density in any modern codec test, unless you're testing specifically for a minority of users.
Jake Archibald, Developer advocate working on Chrome

https://twitter.com/jaffathecake/status/1531337906027102210

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

No branches or pull requests

3 participants