Opened 11 years ago
Closed 10 years ago
#28154 closed enhancement (fixed)
Add get_quality() method for WP_Image_Editor class
Reported by: | alexvorn2 | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Media | Keywords: | has-patch needs-unit-tests |
Focuses: | Cc: |
Description
We have: (http://codex.wordpress.org/Class_Reference/WP_Image_Editor)
get_size() get_output_format() get_suffix() get_mime_type() get_extension()
But no get_quality() function.
Attachments (2)
Change History (8)
#1
@
11 years ago
- Summary changed from Add ge_quality() method for WP_Image_Editor class to Add get_quality() method for WP_Image_Editor class
#3
@
11 years ago
Before to resize an image it is important to get the quality of the source image file,
and after that to resize to the same quality.
For example if we have one 40KB image with low quality, why to resize the image to a smaller one with better quality? when we can resize the image to the same quality and the result will be a smaller image with less size. But if we will resize (300x300) 40KB low quality to high quality (250x250), I think the result will have more than 40KB, maybe 400KB.
#4
@
11 years ago
- Keywords has-patch needs-unit-tests added; reporter-feedback dev-feedback 2nd-opinion removed
We don't know what the original image quality is so your use case will not apply. The bad assumption here would be that the software knows what to do with it.
In the current patch I moved some code around. Reason for this is when we add get_quality() people would be also starting to use set_quality() more. The problem is that when someone uses on of our filters, the filter would always win. Now the default quality value would only be used when no one had set the quality before.
It also abstracts $this->quality away that it's only used in WP_Image_Editor. For now the property stays protected due backwards compatibility. I was thinking about a get() method which sets the value when $this->quality is false.
I will check if we have unit tests for this and add them in case we don't
Is there a use case here, or just accessor parity?
Would adding this to the abstract class
WP_Image_Editor
(as well asWP_Image_Editor_Imagick
andWP_Image_Editor_GD
) have any affect on backwards compatibility, in the case a third-party is extendingWP_Image_Editor
?