WordPress does not respect the bit-depth of the original image when resizing

[qdinar]

i have uploaded 8 bit depth indexed color png, near 1400x1800 size image in wordpress and inserted it into post , and original image was near 500 kB and the smaller width-height version made by wp is near 1400 kB, because it is 24 or 32 bits per pixel png.
(this is useless. i have edited html code to use full version because it is smaller by weight and it is scaled by size so it is ok).

[dnewton]

This isn't a problem that's unique to WordPress (or ImageMagick); it also happens with Photoshop, etc. I've been doing ​a bunch of tests to try to find better ways to resize images, and this is not an atypical result. See ​this comparison between WordPress, Photoshop, and some of my test data.

Basically, when the images are resized there's some smoothing/aliasing that happens, which results in colours that weren't in the original. More colours = bigger file size. One possible way to handle this in WP could be to do the normal resize, check if it's bigger than the original and, if so, do another resize with more aggressive (or any in the case of PNGs) compression.

[joemcgill]

I'd make a motion to wont-fix this based on @dnewton's research.

[qdinar]

i think if indexed i.e. 256 or less color image is resized it becomes near 16 mln color image. so just it should be transfomed back to indexed color after resize.

[kirasong]

Replying to dnewton:

I've been doing ​a bunch of tests <snip> Basically, when the images are resized there's some smoothing/aliasing that happens, which results in colours that weren't in the original. More colours = bigger file size.

Thanks for the detailed testing!

While I can see how dithered images could look moderately better, I'd tend to think the more expected behavior from users would be to maintain bit-depth where we can. Do you have some examples of images where maintaining bit-depth during resize is particularly undesirable?

[dnewton]

Replying to DH-Shredder:

While I can see how dithered images could look moderately better, I'd tend to think the more expected behavior from users would be to maintain bit-depth where we can. Do you have some examples of images where maintaining bit-depth during resize is particularly undesirable?

I haven't checked that exactly. I have looked at lowering bit depth in general, but just to arbitrary levels, not based on what the input was. I've also looked at matching the number of colours in the output to the number of colours in the input. Both of those had fairly bad results — the image quality suffered quite a bit. If there's interest, I can queue up a test for maintaining original bit depth for sometime over the next couple of weeks.

[kirasong]

Replying to dnewton:

I've also looked at matching the number of colours in the output to the number of colours in the input. Both of those had fairly bad results — the image quality suffered quite a bit. If there's interest, I can queue up a test for maintaining original bit depth for sometime over the next couple of weeks.

Thanks, if you have a chance, that'd be great. I could also do a less scientific initial test directly with Imagick/WordPress if you (or @qdinar, per the image with the issue) have a preferred set of lower bit-depth images.

[qdinar]

i have tested a 8 bit image, 1749 x 2482, png, 264 kB. another png, 722 x 1024 , 32 bit was created by worpress from it, and it is 834 kB. i have downloaded it and saved it with paint.net program with 8 bits (png) and it has become 162 kB. it is of good quality.

Both of those had fairly bad results — the image quality suffered quite a bit

I think, if colors are many like 256, or if resulting image has several more colors than input image, for example, if input is 8 colors and result is 12 colors, probably it should be OK. because the several additional tones can be used for antialiasing at edges.

[qdinar]

i have tried corel draw x6 to save (export) 6 colors pdf as 6 or more colors png, but it did not choose right colors, only with many colors like 16 or 24 i could get proper image, then i saved it as 24 bit png and opened and saved with paint.net with 8 colors >not, 8 bits< and it made it well.

so imagick also may have problems, i do not know. there are several methods of choosing colors in corel draw, but maybe, i am not sure, paint.net worked better for me, ie, maybe, it managed to make better result with 8 colors, though "adaptive" method or other in corel draw, maybe, produced image of same quality with 8 colors. >2015-10-03 : i was wrong here. paint.net does not have option to make 8 color png, only 8 bit png. <

(content of the images i deal with are tables with some ornaments around it, some parts of ornaments may be with gradients).

[joemcgill]

#34123 was marked as a duplicate.

[kirasong]

Related: #33642

[kirasong]

In 36700:

Media: Optimize Imagick settings for quality and filesize

• Resamples and sharpens larger images before resize.
• Uses imagick::FILTER_TRIANGLE for a smoother resize.
• Introduces WP_Image_Editor_Imagick::thumbnail_image() protected method to efficiently resize images. Similar to the functionality of Imagick's thumbnailImage().
• Introduces WP_Image_Editor_Imagick::strip_meta() protected method and image_strip_meta filter that, by default, strip image profiles to reduce file size, while leaving color profiles intact.

See: #33642, #30402, #28634.
Props: joemcgill, dnewton, mikeschroder.

[qdinar]

// Limit the  bit depth of resized images to 8 bits per channel. 
if ( 8 < $this->image->getImageDepth() ) { 
$this->image->setImageDepth( 8 );
} 

without additional conditions - it is in try {} in function thumbnail_image {} - i think this is probably not very well because probably jpeg resizes to jpeg with 24 bit rgb image, and only indexed images should be resized to indexed images. but i do not know and think probably setImageDepth ( 8 ) sets 8 bit indexed image. anyway , 8 bit is probably too small for jpeg or not supported, and, if it is 8 bit rgb image, it is also not optimal, probably 8 bit indexed image is better, because it can better fit needed colors.

[DrewAPicture]

In 36846:

Docs: Improve the hook doc summary for the image_strip_meta filter, introduced in [36700].

See: #33642, #30402, #28634. See #35986.

[DrewAPicture]

In 36847:

Docs: Improve DocBlock syntax and add a missing @return notation for WP_Image_Editor_Imagick::strip_meta(), introduced in [36700].

See: #33642, #30402, #28634. See #35986.

[dd32]

#39456 was marked as a duplicate.