You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To further reduce bytesize, Adept needs a more granular approach to compression.
As of now, the only decisive factor if we can apply high compression to a tile is the black-white median decimal "0.825". If a tile ranks below that threshold, it gets compressed more heavily.
We can introduce a multi-threshold step system here that e.g. applies no compression, a little compression (~q=75) or high compression of the median is zero. This way, Adept may be able to save more bytes.
The text was updated successfully, but these errors were encountered:
I had the same idea while fiddling with SaliencyDetector. There may be a way to use variable compression ratios based on the output luminosity of --blocks or --qblocks option already. Or average the luminosity of the default output with imageMagic to achieve the same effect.
I agree, something more than an "on/off" compression could be desirable, and may yield better results.
To further reduce bytesize, Adept needs a more granular approach to compression.
As of now, the only decisive factor if we can apply high compression to a tile is the black-white median decimal "0.825". If a tile ranks below that threshold, it gets compressed more heavily.
We can introduce a multi-threshold step system here that e.g. applies no compression, a little compression (~q=75) or high compression of the median is zero. This way, Adept may be able to save more bytes.
The text was updated successfully, but these errors were encountered: