As mentioned in #8, ICO is a container format, which raises the question of which image dimensions should be retrieved. I agree with the comment there that the largest size is probably the most helpful to end users, and short of modifying the API (probably not a good idea) i think it's the best solution.
It's possible that it'd be even more helpful to return the size of the "highest quality" image contained, using some measure of size, bit depth, color planes, and encoding (ICOs can contain other formats such as PNGs), but due to complexity I think that it's fine to just take the largest. If it happens to be monochromatic, so be it. In practice I think you usually expect ICOs to just contain different scale versions of the same image so it doesn't end up mattering.
Partial header behavior
If the ICONDIR header specifies that there will be several image entries, but we run out of bytes before we parse them all, I think we should return the largest one found so far, rather than an error. If we were reading from a file and hit EOF, then we'd want to return an ImageError::CorruptedImage, but if reading from a partial image file with blob_size() giving back a size is preferable.
Modifying Ord for ImageSize
When writing the logic to take the largest image, I realized that ImageSize already derived Ord. While it's probably not an issue in practice (because most ICO images are squares) I think that using the area of an image would be a more natural way to order them by size. If this isn't wanted, I can revert the modified Ord/PartialOrd impls and let it take the widest rather than largest image since that's the current behavior.
This PR adds support for the ICO format.
ICO format complications
As mentioned in #8, ICO is a container format, which raises the question of which image dimensions should be retrieved. I agree with the comment there that the largest size is probably the most helpful to end users, and short of modifying the API (probably not a good idea) i think it's the best solution.
It's possible that it'd be even more helpful to return the size of the "highest quality" image contained, using some measure of size, bit depth, color planes, and encoding (ICOs can contain other formats such as PNGs), but due to complexity I think that it's fine to just take the largest. If it happens to be monochromatic, so be it. In practice I think you usually expect ICOs to just contain different scale versions of the same image so it doesn't end up mattering.
Partial header behavior
If the ICONDIR header specifies that there will be several image entries, but we run out of bytes before we parse them all, I think we should return the largest one found so far, rather than an error. If we were reading from a file and hit EOF, then we'd want to return an
ImageError::CorruptedImage, but if reading from a partial image file withblob_size()giving back a size is preferable.Modifying
OrdforImageSizeWhen writing the logic to take the largest image, I realized that
ImageSizealready derivedOrd. While it's probably not an issue in practice (because most ICO images are squares) I think that using the area of an image would be a more natural way to order them by size. If this isn't wanted, I can revert the modifiedOrd/PartialOrdimpls and let it take the widest rather than largest image since that's the current behavior.