Open jaltreuter opened 10 months ago
Your feature request means, provide a enum like .scaleMode
, not the bool .preserveAspectRatio
See SDImageScaleMode
It's already talked in the original PR 2 years ago. This changes is OK but need breaks current API (because, each coder need to implements a scale size calculation, which rely on SDImageCoder scaledSizeWithImageSize:
)
Maybe it's better to kept for 6.0.0 milestone.
Actually it's can be done in 5.x version. The old PreserveAspectRatio
will be deprecated and translated into SDImageScaleModeAspectFit
(for true), and SDImageScaleModeFill
(for false).
You can provide SDImageScaleModeAspectFill
for new option.
But this need upgrade at least 3 repos, I'm afraid I don't have enough time on open-source project for now.
SDWebImageWebPCoder - coder for WebP format. iOS 8+/macOS 10.10+. Based on libwebp SDWebImageHEIFCoder - coder for HEIF format, iOS 8+/macOS 10.10+ support. Based on libheif SDWebImageAVIFCoder - coder for AVIF (AV1-based) format. Based on libavif
Decide to mark this feature request in 5.19.0.
Introduce the new SDWebImageContextImageScaleMode
context option.
The exists SDWebImageContextImagePreserveAspectRatio
will marked as deprecated.
@jaltreuter Please, if you have a time, please check if this PR match your feature request ? There are many issues I need to talk with you.
And I'll release v5.18.4 for another user, the 5.19.0 is kept for this PR's changes.
@jaltreuter There are a known issue. (edge case)
Using asepctFill
, the thumbnail image will be larger than the full size image, which breaks our history assumptions
For example
200 x 40
200 x 200
aspectFill
actually, we need to return you a 1000 x 200
thumbnail image
But ask yourself, is this 1000 x 200
actually a thumbnail ? Even bigger than the full image pixel count ?
Ultimately what I want is for the bitmap image to have the same pixel resolution as the physical pixels on the device that will be rendering my image, so it's as crisp as possible without incurring extra memory overhead.
In the case you described above it's not possible to have a crisp image regardless of the thumbnail size I specify, so my expectation would be that the display should have the image as crisp as possible, and the runtime memory usage should not be inflated by specifying a thumbnail image that's greater resolution than the source image.
If this is complicated for you to implement, maybe there's an alternate approach: allow the user to specify the thumbnail size using a block/closure instead of a pre-specified value. The block would execute after the image is downloaded and have the image size as an argument, so the developer may return a thumbnail size suitable for the layout and the specific image.
Intrpduce a closure during decoding is really ugly API design, and you can not easily put closure inside Objective-C NSDictionary. Because, only Objc block use _NSBlock and it's a OS_Object, the Swift closure is just function pointer in implementation.
This is why the API we use that response modifier, request modifier, data decrypter, using a strange protocol to put into SDWebImageContext. And a dummy object with closure initializer (Still many people don't even notice why this exists)
So, for your updated feature request, I decide to still mark this as 6.0 feature request, and blocked by the re-written of API using Swift. p
@jaltreuter Or for your feature request
Can you use Transformer instead ? Transformer can tweak to get a UIImage in, and output a UIImage out.
So you can grab image size, do calculation by what you want. The call the proper API like our UIImage.sd_scaledImageWithSize or third party API for output
Read more: https://github.com/SDWebImage/SDWebImage/wiki/Advanced-Usage#image-transformer-50
You can create a closure based transformer who take a context. for example, your image view size. Like
let transfomer = MyClosureTransformer {
image in
let thumbnailSize = imageView.size
let imageSize = image.size
let scaledSize = doMath(imageSize, thumbnailSize)
let output = image.sd_scaledImage(size: scaledSize, scaledMode : .aspectFit)
return output
}
The only difference between thumbail decoding and resize transfomer is whether it need the full size image. Transformer need additional full size memory just for temporary, but the final image is dependends on what your output is.
Issue Info
Feature request
Right now if I specify a context like
[.imageThumbnailPixelSize: CGSize(200, 200)]
and the downloaded image has a 1:2 aspect ratio, the resulting image will have a size of 100 x 200. This is convenient when using the.scaleAspectFit
content mode of UIImageView, because the pixel size of the image will exactly match the pixel size in which my image is rendered.However if I'm using the
.scaleAspectFill
content mode, it doesn't work as well. If I'm using the same context and downloaded image as described above, the resulting 100 x 200 image will be scaled up to fill the frame. Effectively I end up with a 100 x 100 image in a 200 x 200 frame, and the image appears grainy as a result.This could be addressed by a new boolean in the context dictionary, which would specify whether - if
SDWebImageContextImagePreserveAspectRatio
is true - a downloaded image should be adjusted to fit or to fill theSDWebImageContextImageThumbnailPixelSize
.