It's a history issue of SDAnimatedImage. It was not designed to support Static Image at the beginning for long years, but someday, a user complains about this and wants this feature. So I added static image support in #3626

Some of sd_XXX property is not designed to run on SDAnimatedImage in my original design. The original design from me is to always check with protocol or subclass from the caller...

SDImageFormat format;
UIImage *image;
if ([image isKindOfClass:SDAnimatedImage.class]) {
    format = [image animatedImageFormat];
} else {
    format = image.sd_imageFormat;
}

After #3626, I've fixed some of them, but not all of them. It's OK to merge this PR, but I doubt this will make things more and more difficult to maintain. Should all the sd_XXX property works on SDAnimatedImage ?

Because in some use case, SDAnimatedImage is different from UIImage, we can not hide the implementation details between these two classes. So as user, you should better take care of this specify type by your hand, especially when you want to query frames, data buffer and other metadata which only available on animated format (not available on UIImage class from UIKit)

By the way, your comment here:

When a static image is loaded into SDAnimatedImage, the sd_imageFormat remains unset

Is not correct.

Check the UIImage.sd_imageFormat implementation, it will fallback to use https://developer.apple.com/documentation/coregraphics/1456067-cgimagegetuttype . Which can actually get the UTType and convert to SDImageForamt

Only if you use the Force Decoding feature, which will remove the ImageIO backed property and cause this UTType missing. (Force Decoding defaults to ON, you can use SDImageCoderHelper.ForceDecodePolicy to control the behavior)

It's OK I can just merge this, and remove that setSd_imageFormat: override method by my hand...

Thank you for reviewing my PR. I can certainly remove that override. I mainly left it there to comment on the situations in which the user might expect it to be triggered.