Add ICO and CUR file decoder.

[frg2089]

Prerequisites

• [x] I have written a descriptive pull-request title
• [x] I have verified that there are no overlapping pull-requests open
• [x] I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules :cop:.
• [ ] I have provided test coverage for my change (where applicable)

Description

• Make the Bmp Decoder Core to support ICO's data.
• :tada: Add ICO Encoder.
• Add ICO Decoder.
• Add ICO Image Format Detector.
• :tada: Add CUR Encoder.
• Add CUR Decoder.
• Add CUR Image Format Detector.

Some Questions

[!WARNING] We don't support bmp palettes yet.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Poker-sang]

Even though there is no magic head for ICOs, should we still provide IcoImageFormatDetector as well? In order to support Image.Load<TPixel>().

And should we name the classes with Ico instead of Icon?

[JimBobSquarePants]

Even though there is no magic head for ICOs, should we still provide IcoImageFormatDetector as well? In order to support Image.Load<TPixel>().

And should we name the classes with Ico instead of Icon?

How do you identify without leading bytes?

[Poker-sang]

Maybe we can combine an ICODir and an entry, and think of it as the header of an ICO file.

Or we just provide a decoder, but this decoder will not be used without specification.

[frg2089]

Maybe we can combine an ICODir and an entry, and think of it as the header of an ICO file.

Or we just provide a decoder, but this decoder will not be used without specification.

I think we can do without providing IconImageFormatDetector. Because nobody cares if unknown streams are ICOs. They are usually not transmitted without filename. So we should just provide a decoder and use it directly.

like this

using SixLabors.ImageSharp.Formats.Icon;

async using var fs = File.OpenRead(@"xxx.ico");
var ico = IconDecoder.Instance.Decode(new (), fs);

[Poker-sang]

We actually have an open discussion supporting tiffs with multisize frames. It would be good to split any changes to the tiff decoder out so we can draw the pixel data on the frame.

@JimBobSquarePants Yes. I have reverted all changes to tiff files.

[frg2089]

You've gone the opposite direction to how I hoped I'm afraid here. Please let me know if you need further guidance and I'll try my best to explain.

I refactored the code. Now it doesn't have the IcoPngFrameMetadata, IcoBmpFrameMetadata and the corresponding Cur variants. We can use GetFormatMetadata(XXXFormat.Instance) (which isn't there yet) to get specific metadata. If I'm not doing this the right way, I'm probably not understanding what you're really thinking.

[JimBobSquarePants]

I'm going to write some code to your fork....

OK. So, I've refactored the base decoder to be more efficient and allow us to gather the correct metadata from the png/bmp frames.

I've added a bunch of TODOs in the code also. Please let me know if anything is not clear.

[JimBobSquarePants]

I have some questions about how to store PngMetadata and BmpMetadata.

We should store BitsPerPixel property for encoder. The ICO file may have more than one PNG data.

I’d store that in the Ico/Cur frame metadata. I’d make it an enum though (it’s a fixed range based on available bmp/png fixes)

[JimBobSquarePants]

Apologies for the radio silence over the last few weeks. I've been very busy fixing up the animation behavior for v3.1

[frg2089]

Do we have some new ways to save frames of different sizes yet?

[JimBobSquarePants]

Do we have some new ways to save frames of different sizes yet?

You encode the size stored in the metadata. Pixel buffers can be constrained to regions

[JimBobSquarePants]

@frg2089 Thanks for all your effort so far. It's been tricky for me to review as I've just moved house and have no real internet just now. I'll be able to do a proper review next week though.

[JimBobSquarePants]

I'm going to have a look at how we manage the sizes in the encoding options. I want to come up with the best possible design so I will look for inspiration in other libraries.

[JimBobSquarePants]

@Poker-sang @frg2089 Thanks for your patience.

I think this is in a really good place now. I can do any additional changes (potentially palette handling) once merged.

The only thing I'd like to add is some more tests to ensure we can encode and decode the files. I scoured the internet and managed to find some test files here.

https://github.com/SystemRage/Iconolatry/tree/master/test_decode

I cannot add the image to your fork due to LFS permissions issues with GitHub but would be very grateful if you were able to do so.

[frg2089]

The only thing I'd like to add is some more tests to ensure we can encode and decode the files. I scoured the internet and managed to find some test files here.

Done!