Update to ImageSharp v3.1.12

[Erik-White]

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

This updates ImageSharp.Textures to use the latest public release of ImageSharp, version 3.1.12
The license has been updated to the Six Labors Split License

It also updates relevant dependencies:

• SixLabors.SharedInfrastructure submodule to 353b9af to mirror the release/v3.0.x of ImageSharp
• updates formatting and code to conform to rules in SixLabors.SharedInfrastructure (nullability etc)
• updates all test dependencies

I saw the comment that this repo is not maintained and I understand that you don't have time for it, but it would be shame to let all the obvious effort that has gone into this to go to waste! I would like to find a path forward where I (and I'm sure others) can make use of it, as well as contribute, without being a burden on the ImageSharp team.

(Apologies for the size of the diff, the license changes forced a lot of noise with the updated file headers)

[CLAassistant]

All committers have signed the CLA.

[JimBobSquarePants]

Thanks @Erik-White

I would love to get this kick started again once I do the next major releases of the main libraries. I've actually had very little to do with the code so will need to conduct a thorough architectural review following a merge.

[Erik-White]

Great! Thanks for your feedback

[Erik-White]

I have updated the Texture.From* methods to return exceptions instead of nullable types

[Erik-White]

What are the chances of getting this merged soon? I love to be able to start using it, and have been working on adding ASTC support for ktx and other improvements - but this is needed first.

It would also be great if it could be published as a pre-release package on the standard nuget feed, any chance of that happening?

[Erik-White]

Is there a StyleCop rule that has changed in shared-infrastructure somewhere?
The build is now failing on SA1010: Opening square brackets should not be preceded by a space, but if I remove the space then I get SA1003: Operator '=' should be followed by whitespace!

I could probably just work around it with new(), but that seems a bit silly

[brianpopow]

What are the chances of getting this merged soon? I love to be able to start using it, and have been working on adding ASTC support for ktx and other improvements - but this is needed first.

The chances are very high. I am glad to see some interest in the project again!

It would also be great if it could be published as a pre-release package on the standard nuget feed, any chance of that happening?

There is already a build step, which pushes to the myget feed, but I do not know If this is still working or not. In the ImageSharp main project we now use Feedz.io now instead of myget.

Is there a StyleCop rule that has changed in shared-infrastructure somewhere?
The build is now failing on SA1010: Opening square brackets should not be preceded by a space, but if I remove the space then I get SA1003: Operator '=' should be followed by whitespace!

This stylecop rule seem not to make sense to me. There is no explicit rule configured for this as far as I can tell. Could you try to update the shared infrastructure to the latest commit of the main branch?

[Erik-White]

The chances are very high. I am glad to see some interest in the project again!

Excellent!

Could you try to update the shared infrastructure to the latest commit of the main branch?

I can try. Is there any risk of problems if it's not kept in sync with the commit used by ImageSharp 3.1.12?

[brianpopow]

I can try. Is there any risk of problems if it's not kept in sync with the commit used by ImageSharp 3.1.12?

I dont think so, but maybe I overlook something. It is a good idea to use the commit used by ImageSharp 3.1.12

[Erik-White]

I had been trying to keep it to the same commit as was used in the particular ImageSharp version. But, updating it to the latest as you suggested fixed the issue with no apparent problems so I'll go with that.

[brianpopow]

@Erik-White the build works now fine in release mode, but the tests fail on ubuntu (on windows it seems to work). I will try to figure out whats wrong tomorrow

[Erik-White]

Thanks for running the build again, but I am now at a bit off a loss why all the tests are failing with System.NotSupportedException : Invalid DDS magic value.

I can only think that maybe there is a problem with the LFS checkout somehow and that the actual files are not present, only the file pointers?? Everything is passing locally

Edit: just saw your comment - that's bizarre that it's only Ubuntu

[brianpopow]

I can only think that maybe there is a problem with the LFS checkout somehow and that the actual files are not present, only the file pointers?? Everything is passing locally

@Erik-White You are right, that is what is happening here. I am not sure why though.

edit: Could the spaces in the file names be a problem for git lfs?
edit2: My second guess would be that the file extensions of the dds file are upper case, but tracked by gitlfs are only lowercase dds files. On windows this does not matter, but it would matter on linux

[Erik-White]

I had a look at the pipeline and did some searching around, I think/hope I know what the issue is now.

The workflow performs git lfs pull on a shallow clone (line 48) before unshallowing the repository (line 58), which apparently can cause LFS files to remain as pointers instead of downloading actual content. On Ubuntu, LFS has stricter behavior with shallow clones and may fail to download LFS files correctly when the full git history isn't available.

I copied the checkout steps from the main ImageSharp CI build pipe, hopefully that will sort it.

[Erik-White]

Well that didn't help at all! I'll have to try some thing out in my repo, where I can trigger the builds myself and experiment a bit, and then get back to you

[brianpopow]

Well that didn't help at all! I'll have to try some thing out in my repo, where I can trigger the builds myself and experiment a bit, and then get back to you

Ok, thanks for looking into the issue. If you struggle to find a solution for this issue, we could also consider disabling the tests for ubuntu temporary, since I do not think your changes in this PR have introduced the issue. We could the try to find a solution for that in a follow up PR.

I still think it could have something todo with the casing of the file endings, but it is just a wild guess.

[Erik-White]

Your hunch about the file endings was correct! Renaming them to lowercase did the trick

I'm quite confused though, was the pipeline not working before I opened this PR? I don't think any of my changes would have caused the issue