-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Support higher-quality S3TC compression modes #21167
Conversation
This seems compatibility breaking, unless if the squish module was added in 3.1. Also, I don't understand why using an obscure float number instead of an enum. The float does not seem to be used anywhere but in selecting the compression mode. |
Squish has been in for years, but it's always been using its lowest-quality compression mode (range fit). The float parameter is already used by the ETC importer to control for import speed/quality tradeoffs. |
OK, I un understand why you used a float value but I am not sure the image_compress_squish is the best place to do the float -> compression mode conversion. For a cleaner API, I would have an enum mode parameter for this function and select the correct mode in the Image compress function. But that's my humble opinion on that.
So unless if you move the parameter to the end and give it a default value, this is thus compatibility breaking change. |
@groud The method is not bound to scripting languages, so it doesn't break compat per se for projects. But it does mean that the previously ignored lossy ratio will now be used and produce better compressions at high ratios - but I think that's fine for 3.1. |
And the float
|
OK I though it was bound. It's not compatibility breaking then :). If the p_lossy_quality is used everywhere else, I agree thus change might be out of the scope of this PR. Still I find weird having an API where you can provide any float value between 0 and 0.75 and which does not changes the output result by any mean. That is why I suggested moving the float value outside of the squish API and do the conversion outside. |
I think there are simplicity benefits to having a single "quality" parameter, but possibly also drawbacks of the same setting not making sense everywhere. (And range fit as default isn't something I'm thrilled with anyway - The quality is poor.) |
What I meant is that, indeed, the single parameter in the Image::compress function totally makes sense. But in the image_compress_squish function, it does not. Anyway, this is a cosmetic change. As the PR does not involves any compatibility issue it can be merged as is. ;) |
This needs a rebase after the BPTC merge. |
330650a
to
4cd8666
Compare
Rebase done. |
Thanks! |
Switches Squish compression mode to cluster fit at >0.75 and iterative cluster fit at >0.85 lossy quality. Both get substantially better quality than range fit.