Add ICO and CUR file decoder.

[frg2089]

Prerequisites

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

Description

• Make the Bmp Decoder Core to support ICO's data.
• 🎉 Add ICO Encoder.
• Add ICO Decoder.
• Add ICO Image Format Detector.
• 🎉 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.

[JimBobSquarePants]

Thanks for this, your efforts are really appreciated! There's a lot to discuss.

Some notes...

I don't think it's a good idea to merge the two formats. We're creating unnecessary ambiguity. If you look at format metadata, we avoid exposing unconstrained configuration values.

It's imperative that the pixel data is drawn on the frame and not resized. Position 0,0, seems sane as an origin. Any other behavior such as resizing or introducing new image types or editing existing signifies a major breaking change for the library.

We need an encoder. I can't accept code against main without one as we need to ensure that we have covered encoding requirements in the format design.

I'll be honest and say this won't get merged before V4. There's a lot to do to ensure that the decoder is safe (I haven't checked bounds handling and EOF detection) and the design practical.

[JimBobSquarePants]

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.

[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.

[frg2089]

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.

[frg2089]

I think the PNG data may not be the only one. ICO file may have 2 and more PNG data.
So, we should store the PngMetadata in the FrameMetadata instead of the ImageMetadata.

[JimBobSquarePants]

They’re just for easy conversation really. See below re bits per pixel. You may want to capture palette data also

[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

[frg2089]

SA1010
Should I avoid this syntax?

[JimBobSquarePants]

You should be fine now that I've updated the StyleCop version.