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
The quality parameter seems to have no predictable pattern to its behavior.
Looking at the description, one is led to believe that setting to 100 will bypass compression, and no compression will be applied for PNG images. To test this, I tried various experiments with the following settings:
A. maxWidth = 800
B. maxHeight = 1000
C. quality = 90, and compressFormat is same as source image
png image of 512x512, size 9.6 KB => results in 18.6 KB, with no resize. Why did the file size double?
jpeg image of 582x864, size 62KB => results in 94.5KB, with no resize. Why did the file size increase?
A. maxWidth = 800
B. maxHeight = 1000
C. quality = 100, and compressFormat is same as source image
png image of 800x800, size 67 KB => results in 170 KB, with no resize. Why did the file size double?
jpeg image of 862x282, size 31KB => results in 73 KB, with resize to 800px. Why did the file size more than double?
The text was updated successfully, but these errors were encountered:
Part of the explanation is for PNG. According to the documentation on toDataURL, the second parameter is ignored for lossless encoding, such as when creating PNG. There appears to be no way to control the compression rate.
It only applies to lossy formats like JPEG and WebP. Which also means that lossless WebP will become lossy after resaving them to WebP.
The reason JPEG becomes bigger, might be in their very nature: re-encoding JPEG means the existing JPEG artefacts are now part of the "original" pixels that needs to go through encoding, which effectively means you'll be getting double JPEG artefacts. Re-encoding a JPEG as another JPEG is never a great idea, unless you're significantly reducing its dimensions.
I suppose resizing images through the browser is just as limited as it is. The only way around this, is to go full serverside. Or I suppose include a full custom library like Sharp on the clientside, which I would not recommend for regular websites, only for locally installed webapps (such as React Native, or Electron).
The quality parameter seems to have no predictable pattern to its behavior.
Looking at the description, one is led to believe that setting to 100 will bypass compression, and no compression will be applied for PNG images. To test this, I tried various experiments with the following settings:
A. maxWidth = 800
B. maxHeight = 1000
C. quality = 90, and compressFormat is same as source image
A. maxWidth = 800
B. maxHeight = 1000
C. quality = 100, and compressFormat is same as source image
The text was updated successfully, but these errors were encountered: