ImageSharp.Web 2.0.0 release?

[marklonquist]

Hi

When will version 2.0.0 be released of this? :) We just got ImageSharp 2.0.0, but sadly it's not useful for us until ImageSharp.Web has followed up. :D

[JimBobSquarePants]

Are you kidding me?

[marklonquist]

Haha! I'm so sorry Jim.

I've tried just updating ImageSharp to 2.0.0 but gets a method not allowed error once I do.

So just wanted to check what the expected timeline is. 😅

[JimBobSquarePants]

Tell you what... Cast your eye over this for me and let me know if you think it makes sense.

#221

If we get this passed merged I see only one minor tweak required to the physical provider and cache..

[ronaldbarendse]

@JimBobSquarePants are you planning on doing a release candidate for v2? Would love to test everything out on a nightly Umbraco 10 build and validate whether everything works and custom providers/processors can be implemented correctly!

[JimBobSquarePants]

I didn’t plan to. Why not use the MyGet builds?

[ronaldbarendse]

I wasn't sure about the state of the alpha builds, but if the latest version can be considered identical to a release candidate, I'll add the MyGet feed and install from there 👍🏻

[JimBobSquarePants]

Pretty much. I'm unlikely to make further breaking changes. Maybe just add some helper utilities.

[ronaldbarendse]

Before releasing the final v2 version, a good exercise would be to check whether it's possible to change the new default configuration to function the same as v1.

As far as I'm aware, you'd need the following setup to ensure the same cache folder structure is used, optionally disable EXIF orientation-aware resizing, use the legacy cache key and the WebRootImageProvider:

services.AddImageSharp(options =>
{
    // Set to previous default value of CachedNameLength
    options.CacheHashLength = 8;

    // Use similar command parsing as in v1
    options.OnParseCommandsAsync = c =>
    {
        if (c.Commands.Count == 0)
        {
            return Task.CompletedTask;
        }

        // It's a good idea to have this to provide very basic security
        uint width = c.Parser.ParseValue<uint>(c.Commands.GetValueOrDefault(ResizeWebProcessor.Width), c.Culture);
        uint height = c.Parser.ParseValue<uint>(c.Commands.GetValueOrDefault(ResizeWebProcessor.Height), c.Culture);
        if (width > 4000 && height > 4000)
        {
            c.Commands.Remove(ResizeWebProcessor.Width);
            c.Commands.Remove(ResizeWebProcessor.Height);
        }

        // Disable EXIF orientation-aware resizing
        if (c.Commands.Count > 0)
        {
            c.Commands.Add(ResizeWebProcessor.Orient, bool.FalseString);
        }

        return Task.CompletedTask;
    });
})
.Configure<PhysicalFileSystemCacheOptions>(options =>
{
    // Ensure this value is the same as CacheHashLength to generate a backwards-compatible cache folder structure
    options.CacheFolderDepth = 8;
})
.SetCacheKey<LegacyV1CacheKey>()
.ClearProviders()
.AddProvider<WebRootImageProvider>();

[JimBobSquarePants]

Yep that looks about right. Thanks for writing it up. I'll be stealing it for the docs!

[ronaldbarendse]

I've spotted an issue with the above configuration: disabling the EXIF orientation-aware resizing adds a command, which will generate a different cache key and make generating a backwards compatible cache folder structure and cache key useless (it won't match any existing cached files anymore). Leaving it enabled will also cause issues, because you can then get different results depending on whether the image is retrieved from cache or newly processed.

A possible solution would be to always remove the ResizeWebProcessor.Orient command from the cache key generation in LegacyV1CacheKey. Because this command wasn't used in V1, this shouldn't case any other side-effects...

The release notes/docs should probably also give a warning/strong advice to clean the image cache if you're upgrading, but not resetting your configuration to the above.

[JimBobSquarePants]

It's out now.