V3 : Fix GIF, PNG, and WEBP Edge Case Handling #2882

JimBobSquarePants · 2025-02-07T05:51:25Z

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

Fixes #2866
Fixes #2862

There's quite a lot going on here:

Both GIF and WEBP decoders were not handling frame disposal properly.
GIF Decoder background color handling was incorrect.
GIF Encoder incorrectly used global palette for local root frame.
WEBP Decoder did not clear some buffers on load where it should.
PNG Encoder palette animations did not work properly
Fixed pixel sampling in Wu and Octree quantizers
Improved accuracy for matching first 512 colors in EuclidianPixelMap.

I'll have to manually rework this for V4 as the code base has migrated significantly there.

Copilot

Copilot reviewed 5 out of 16 changed files in this pull request and generated no comments.

Files not reviewed (11)

tests/Images/External/ReferenceOutput/GifDecoderTests/Issue1962_Rgba32_issue1962_tiniest_gif_1st.png: Language not supported
tests/Images/External/ReferenceOutput/GifDecoderTests/Issue2012BadMinCode_Rgba32_issue2012_drona1.png: Language not supported
tests/Images/Input/Gif/issues/issue_2866.gif: Language not supported
tests/Images/Input/Webp/issues/Issue2866.webp: Language not supported
src/ImageSharp/Formats/Gif/GifEncoderCore.cs: Evaluated as low risk
tests/ImageSharp.Tests/TestUtilities/ReferenceCodecs/MagickReferenceDecoder.cs: Evaluated as low risk
src/ImageSharp/Formats/Webp/Lossy/Vp8Decoder.cs: Evaluated as low risk
src/ImageSharp/Formats/Webp/BitReader/BitReaderBase.cs: Evaluated as low risk
tests/ImageSharp.Tests/Formats/Png/PngEncoderTests.cs: Evaluated as low risk
tests/ImageSharp.Tests/TestImages.cs: Evaluated as low risk
src/ImageSharp/Formats/Webp/WebpBlendMethod.cs: Evaluated as low risk

Comments suppressed due to low confidence (2)

tests/ImageSharp.Tests/Formats/Gif/GifEncoderTests.cs:389

[nitpick] The test method name GifEncoder_CanDecode_Issue2866 is misleading since it is testing encoding, not decoding. It should be renamed to GifEncoder_CanEncode_Issue2866.

public void GifEncoder_CanDecode_Issue2866<TPixel>(TestImageProvider<TPixel> provider)

src/ImageSharp/Formats/Webp/WebpAnimationDecoder.cs:89

The comment should reflect the correct type for backgroundColor, which is TPixel instead of Color.

/// <param name="backgroundColor">The default background color of the canvas in.</param>

This reverts commit 33e5cbf.

antonfirsov · 2025-02-25T22:39:22Z

This is quite a huge change, but I'm planning to take a high-level look in the coming days.

JimBobSquarePants · 2025-02-26T05:25:15Z

This is quite a huge change, but I'm planning to take a high-level look in the coming days.

Thanks! I have a V4 version also that I’m going to push, lots of similarities but also some additional changes.

…elMap{TPixel}.cs Co-authored-by: Anton Firszov <[email protected]>

brianpopow · 2025-03-03T12:07:47Z

@JimBobSquarePants I think it would be good to add a few more test case to verify everything works as expected. Here is a github repository with some gif images generated with imagemagick: gif-test-suite, which I think could be useful testcases.

I can help with adding tests, I have some time in the next few days.

JimBobSquarePants · 2025-03-03T14:07:45Z

That would be awesome if you could thanks!

Directory.Build.props

brianpopow · 2025-03-03T18:56:27Z

With some of test images I have added with f80aa76, the output of ImageSharp does not match what imagemagick would produce, which may indicate an error.
For example, the image:

animated_transparent_frame_restoreprev_loop.gif

The output from ImageSharp looks like this:

I am not sure yet why. I will try to figure out what's wrong tomorrow.
Also notice: It could be not related to changes introduced with this PR.

To extract the images with imagemagick, the following command can be used:

 magick convert -coalesce animated_transparent_frame_restoreprev_loop.gif[0-4] out.png

JimBobSquarePants · 2025-03-03T23:31:26Z

@brianpopow That looks like something to do with palette reading though the last frame suggests an additional bug.

brianpopow · 2025-03-05T12:36:35Z

@brianpopow That looks like something to do with palette reading though the last frame suggests an additional bug.

@JimBobSquarePants It seems that the issue is a regression from version 2.1.9 to 3.0.0. It is an issue with handling the disposal method RestoreToPrevious. When I change it back to how it was in 2.1.9, the images look again like expected in the ActualOutput folder.

The weird thing is that when I save the frames like this:

var img = Image.Load<Rgba32>(imagePath);
for (int i = 0; i < img.Frames.Count; i++)
{
    using Image frameImage = img.Frames.CloneFrame(i);

    frameImage.Save($"output_{i}.png");
}

The images still look black and white. I am not sure what I do wrong here with saving the frames.

JimBobSquarePants · 2025-03-06T04:39:21Z

@brianpopow That looks like something to do with palette reading though the last frame suggests an additional bug.

@JimBobSquarePants It seems that the issue is a regression from version 2.1.9 to 3.0.0. It is an issue with handling the disposal method RestoreToPrevious. When I change it back to how it was in 2.1.9, the images look again like expected in the ActualOutput folder.

The weird thing is that when I save the frames like this:
var img = Image.Load<Rgba32>(imagePath);
for (int i = 0; i < img.Frames.Count; i++)
{
    using Image frameImage = img.Frames.CloneFrame(i);

    frameImage.Save($"output_{i}.png");
}
The images still look black and white. I am not sure what I do wrong here with saving the frames.

I can fix restore to previous behavior easily enough but I'm seeing some odd behavior in ImageMagick for this image and others. It doesn't seem to follow the gif89a specification at all regarding GCE transparency and is setting entries at a given index with an alpha of zero regardless of whether there is a transparency flag. @dlemstra Any idea why this is?

JimBobSquarePants · 2025-03-12T22:51:42Z

@brianpopow I figured out why the output is wrong when cloning. The current code attempts to encode the image using the palette data and bit depth extracted from the individual frames however the new frame contains all the data from the combined frame not just te delta. We shouldn't attempt to preserve the palette when converting between formats. I'll push a fix for this today to this branch.

brianpopow · 2025-03-13T12:52:20Z

@brianpopow I figured out why the output is wrong when cloning. The current code attempts to encode the image using the palette data and bit depth extracted from the individual frames however the new frame contains all the data from the combined frame not just te delta. We shouldn't attempt to preserve the palette when converting between formats. I'll push a fix for this today to this branch.

@JimBobSquarePants: I am glad you found the issue, I had trouble making sense out of this behavior.

SpaceCheetah · 2025-03-21T03:53:46Z

Seems the PNG encoder still has trouble for multi-frame cases with "previous" dispose mode. Should make sure it works for all blend modes too, or change the blend mode so it does. Here's a case where the encoder fails, but the decoder succeeds:
Input:

Encoder output:

JimBobSquarePants · 2025-03-24T04:28:38Z

Seems the PNG encoder still has trouble for multi-frame cases with "previous" dispose mode. Should make sure it works for all blend modes too, or change the blend mode so it does. Here's a case where the encoder fails, but the decoder succeeds: Input: Encoder output:

@SpaceCheetah Fixed with 71357d2

antonfirsov

Apologies for the long delay. This is great work and clearly an improvement over the current state. Correct me if I'm wrong, but in my understanding this PR is dealing with 2 relatively separate concerns: (1) fixing edge cases including #2866, (2) preventing quality loss to address #2862.

I have no concerns with (1), but I think there might be some space for improvements regarding (2).

In 4ace814 I did some benchmark extensions. While the original Gif benchmark is targeted at comparing ImageSharp to System.Drawing, benchmarking with a custom decoder setup isn't very representative when we want to track impactful performance changes within the library, since most users will likely go with the default decoder config. For that reason the commit splits the benchmark into two, where EncodeGif_DefaultEncoder benchmarks the default encoder performance. I also added DecodeEncodeGif_* to have benchmark that approximates the typical end-to-end user scenario.

These benchmarks show ~50% regression for EncodeGif_DefaultEncoder and 20%-40% regression for DecodeEncodeGif_DefaultEncoder which would land in a 3.1.* revision update.

Config

BenchmarkDotNet=v0.13.0, OS=Windows 10.0.26100
Intel Core i9-10900K CPU 3.70GHz, 1 CPU, 20 logical and 10 physical cores
.NET SDK=9.0.201
  [Host]     : .NET 6.0.36 (6.0.3624.51421), X64 RyuJIT
  DefaultJob : .NET 6.0.36 (6.0.3624.51421), X64 RyuJIT

`EncodeGif_DefaultEncoder`

`release/3.1.x`

|               Method |      TestImage |         Mean |       Error |      StdDev |  Ratio | RatioSD |
|--------------------- |--------------- |-------------:|------------:|------------:|-------:|--------:|
| 'System.Drawing Gif' | Gif/cheers.gif |     417.4 us |     8.19 us |    13.68 us |   1.00 |    0.00 |
|     'ImageSharp Gif' | Gif/cheers.gif | 258,576.9 us | 5,151.66 us | 5,512.22 us | 623.78 |   32.37 |
|                      |                |              |             |             |        |         |
| 'System.Drawing Gif' |    Gif/leo.gif |     110.1 us |     2.20 us |     5.14 us |   1.00 |    0.00 |
|     'ImageSharp Gif' |    Gif/leo.gif |  23,045.7 us |   370.19 us |   309.12 us | 210.78 |   12.16 |

PR

|               Method |      TestImage |         Mean |       Error |       StdDev |  Ratio | RatioSD |
|--------------------- |--------------- |-------------:|------------:|-------------:|-------:|--------:|
| 'System.Drawing Gif' | Gif/cheers.gif |     417.7 us |     8.26 us |     10.45 us |   1.00 |    0.00 |
|     'ImageSharp Gif' | Gif/cheers.gif | 405,657.8 us | 6,656.34 us | 10,748.74 us | 977.41 |   30.18 |
|                      |                |              |             |              |        |         |
| 'System.Drawing Gif' |    Gif/leo.gif |     109.2 us |     2.18 us |      4.74 us |   1.00 |    0.00 |
|     'ImageSharp Gif' |    Gif/leo.gif |  30,104.5 us |   348.21 us |    325.72 us | 276.99 |   14.94 |

`DecodeEncodeGif_DefaultEncoder`

`release/3.1.x`

|                          Method |      TestImage |       Mean |     Error |    StdDev | Ratio | RatioSD |
|-------------------------------- |--------------- |-----------:|----------:|----------:|------:|--------:|
|                   SystemDrawing | Gif/cheers.gif |   7.140 ms | 0.1384 ms | 0.2732 ms |  1.00 |    0.00 |
|       ImageSharp_DefaultEncoder | Gif/cheers.gif | 426.230 ms | 7.9217 ms | 7.4100 ms | 58.02 |    2.29 |
|                                 |                |            |           |           |       |         |
|                   SystemDrawing |    Gif/leo.gif |   2.021 ms | 0.0390 ms | 0.0571 ms |  1.00 |    0.00 |
|       ImageSharp_DefaultEncoder |    Gif/leo.gif |  35.703 ms | 0.5295 ms | 0.4953 ms | 17.91 |    0.67 |

PR

|                          Method |      TestImage |       Mean |      Error |     StdDev | Ratio | RatioSD |
|-------------------------------- |--------------- |-----------:|-----------:|-----------:|------:|--------:|
|                   SystemDrawing | Gif/cheers.gif |   7.247 ms |  0.1412 ms |  0.2279 ms |  1.00 |    0.00 |
|       ImageSharp_DefaultEncoder | Gif/cheers.gif | 586.890 ms | 11.1193 ms | 20.0504 ms | 81.43 |    2.99 |
|                                 |                |            |            |            |       |         |
|                   SystemDrawing |    Gif/leo.gif |   2.142 ms |  0.0428 ms |  0.0761 ms |  1.00 |    0.00 |
|       ImageSharp_DefaultEncoder |    Gif/leo.gif |  42.617 ms |  0.8244 ms |  0.8097 ms | 20.28 |    1.24 |

Ideas:

Given that Quality loss when quantizing an image that already has (fewer than) 256 colors #2862 complains about quality loss for images with smaller palettes, I wonder if it would make sense to dynamically choose between Coarse and Hybrid depending on the palette size?
If the former idea is not feasible for whatever reason, shouldn't we keep ColorMatchingMode.Coarse as default, at least for 3.1? Note that Quality loss when quantizing an image that already has (fewer than) 256 colors #2862 seems to be the only complaint about the quality gap which makes me think that there might be potentially more users worried about performance.

src/ImageSharp/Processing/Processors/Quantization/EuclideanPixelMap{TPixel,TCache}.cs

antonfirsov · 2025-03-26T00:07:02Z

src/ImageSharp/Processing/Processors/Quantization/EuclideanPixelMap{TPixel,TCache}.cs

+        where TPixel : unmanaged, IPixel<TPixel> => colorMatchingMode switch
+        {
+            ColorMatchingMode.Hybrid => new EuclideanPixelMap<TPixel, HybridCache>(configuration, palette, transparentIndex),
+            ColorMatchingMode.Exact => new EuclideanPixelMap<TPixel, NullCache>(configuration, palette, transparentIndex),


ColorMatchingMode.Exact => new EuclideanPixelMap<TPixel, NullCache>(...)

Nit: This is a bit confusing. Does ColorMatchingMode.Exact mean that there is no caching? Shouldn't then we rename ExactCache to something like AccurateCache?

Also, it might be good to add common EuclideanPixelMap<TPixel, TCache> instantiations to AotCompilerTools.

Yeah, Exact means no cache. Very slow but the results are based on distance matching only. I could rename the internal cache instance if that makes thing clearer. I'll also add to the compiler tools.

JimBobSquarePants · 2025-03-26T00:56:35Z

Thanks @antonfirsov that's very much appreciated!

What I was trying to do by using Hybrid as default was to remove any surprises using the default pipeline, however with the introduction of explicit options that provides clear indication of the default behavior and the power for users to override. I'll default back to coarse caching to maintain current performance.

Using explicit options is the best approach IMO as the length of the palette doesn't directly affect the accuracy of matching. 256 distinct colors would lead to less collisions than 256 shades of gray using coarse caching.

JimBobSquarePants · 2025-03-26T01:28:06Z

@antonfirsov That's the additional changes made now.

There's something weird going on when the coarse cache is enabled. I'm getting less frames than I should which suggests some kind of introduced memory corruption.

Actually, the encoded PNG seems fine, it's our decoder that's messing something up.

antonfirsov

antonfirsov · 2025-03-26T15:37:10Z

src/ImageSharp/Processing/Processors/Quantization/IColorIndexCache.cs

+    private readonly IMemoryOwner<short> bucketsOwner;
+    private MemoryHandle bucketsHandle;
+    private short* buckets;
+
+    // Entries array: stores up to 256 entries.
+    private readonly IMemoryOwner<Entry> entriesOwner;
+    private MemoryHandle entriesHandle;
+    private Entry* entries;


Thoughts for future optimization:

I think it's possible to speed up the AccurateCache by replacing the buckets -> entries double dispatch logic and the linked-list collision management with a single contigous buffer where a constant number of entries is designated for each bucket. Entries belonging to the same bucked would be layed out adjacently in the memory which would improve memory locality. (This would use more memory, but it would be still much less than what CoarseCache is using.)

Moreover, both the coarse and the accurate cache has an index calculation step (GetCoarseIndex and the (key >> 16) ^ (key >> 8) ^ key) & 0x1FF thingie) which can be pre-caluclated for batches of pixels using SIMD. This would require tweaks on the Quantizer API though.

My assumption is that if we would implement both of these changes it would greatly improve quantizer perf, however this assumption has to be proven by profiling first.

Intrigued by the AccurateCache suggestions....

I'm not sure how we could pre-batch the keys though given that they could be any uint value represented by packed Rgba32.

If we had a bulk quantization overload like:

public interface IQuanizer<TPixel> { public QuantizeColors(ReadOnlySpan<TPixel> pixels, Span<byte> output); }

We could first do all the TPixel -> index mappings into a buffer, and then use the indices to look up colors in the second step. Actually, even the second step could be partially vectorized thanks to AVX2 & AVX512 scatter/gather instructions, e.g. VPGATHERDD/_mm256_i32gather_epi32 (Avx2.GatherVector256).

I believe this could do magic to quantizer perf, therefore I recommend to stick with a SIMD-friendly cache algorithms in #2894, so we can vectorize them later. Personally, I prefer some memory penalty over the speed penalty since I think our current quantization is very slow. We need to aim for speeding it up without hurting quality.

Yeah, I see how that would work. I had no idea such a method existed!!

I'm not sure our quantization is actually all that slow though. System.Drawing seems to pass-through the image when it's multi-framed if its unchanged so comparing it against that is not a fair test without performing some sort of operation on the individual frames first.

You'll find that if we benchmark a single frame GIF the results are much closer.

Yeah System.Drawing numbers seem to be fake to me as well. We should rather benchmark against the whatever library that powers Chromium. I may be wrong, but based on what is possible, unfortunately, I don't think our numbers will be close.

JimBobSquarePants added 7 commits February 4, 2025 17:36

Add image and test

6f38753

Fix GIF handling of unused global tables.

a888544

Fix WEBP animation disposal and blending

ef8c79d

Ensure WEBP decoder unsets the restore area.

bd1649d

Fix GIF restore to background behavior and background color assignment.

2b239ec

Remove TODO:

f63ad84

Revert breaking change

7cecea9

JimBobSquarePants added bug formats:gif formats:webp labels Feb 7, 2025

JimBobSquarePants requested review from tocsoft, antonfirsov, dlemstra, brianpopow and Copilot February 7, 2025 05:51

Update build-and-test.yml

9c5bcfa

Copilot AI reviewed Feb 7, 2025

View reviewed changes

JimBobSquarePants added 6 commits February 10, 2025 16:52

Merge branch 'release/3.1.x' into js/fix-2866

386e17d

Fix PNG animation encoding and quantizer output

5d77de9

Fix transparency mode, update quantized refs

6da9bc3

Try bumping to latest SDK

33e5cbf

Revert "Try bumping to latest SDK"

c4d314a

This reverts commit 33e5cbf.

Try casting

67fd9de

JimBobSquarePants changed the title ~~V3 : Fix GIF and WEBP Edge Case Handling~~ V3 : Fix GIF, PNG, and WEBP Edge Case Handling Feb 25, 2025

JimBobSquarePants added the formats:png label Feb 26, 2025

JimBobSquarePants mentioned this pull request Feb 26, 2025

V4 : Fix GIF, PNG, and WEBP Edge Case Handling #2894

Open

4 tasks

JimBobSquarePants added 2 commits February 26, 2025 22:56

Use latest instead of preview to avoid build errors.

d33e6a9

Try explicit langversion

f9f5257

Update src/ImageSharp/Processing/Processors/Quantization/EuclideanPix…

94df8e3

…elMap{TPixel}.cs Co-authored-by: Anton Firszov <[email protected]>

antonfirsov reviewed Mar 3, 2025

View reviewed changes

Directory.Build.props Outdated Show resolved Hide resolved

Additional testcases for gif decoder

f80aa76

Merge branch 'release/3.1.x' into js/fix-2866

78b902b

JimBobSquarePants added 3 commits March 6, 2025 15:33

Fix GIF RestoreToPrevious

6430b8e

Respond to feedback

bf66f24

Add options for color lookup.

b65abe7

Do not copy color tables when transcoding.

eb6b0ab

JimBobSquarePants mentioned this pull request Mar 21, 2025

Fix animated png handling (issue #2708) #2710

Merged

4 tasks

Fix PNG encoder blending.

71357d2

extend gif benchmarks

4ace814

antonfirsov reviewed Mar 26, 2025

View reviewed changes

Revert to coarse cache default, additional feedback.

0ea2404

Fix PNG chunk detection.

efe11dc

antonfirsov approved these changes Mar 26, 2025

View reviewed changes

fix build (add blank lines)

925a651

JimBobSquarePants merged commit 4a8ff2b into release/3.1.x Mar 27, 2025
8 checks passed

JimBobSquarePants deleted the js/fix-2866 branch March 27, 2025 23:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

V3 : Fix GIF, PNG, and WEBP Edge Case Handling #2882

V3 : Fix GIF, PNG, and WEBP Edge Case Handling #2882

JimBobSquarePants commented Feb 7, 2025 •

edited

Loading

Copilot AI left a comment

antonfirsov commented Feb 25, 2025

JimBobSquarePants commented Feb 26, 2025

brianpopow commented Mar 3, 2025

JimBobSquarePants commented Mar 3, 2025

brianpopow commented Mar 3, 2025 •

edited

Loading

JimBobSquarePants commented Mar 3, 2025

brianpopow commented Mar 5, 2025

JimBobSquarePants commented Mar 6, 2025 •

edited

Loading

JimBobSquarePants commented Mar 12, 2025

brianpopow commented Mar 13, 2025

SpaceCheetah commented Mar 21, 2025 •

edited

Loading

JimBobSquarePants commented Mar 24, 2025 •

edited

Loading

antonfirsov left a comment •

edited

Loading

antonfirsov Mar 26, 2025 •

edited

Loading

antonfirsov Mar 26, 2025

JimBobSquarePants Mar 26, 2025 •

edited

Loading

JimBobSquarePants commented Mar 26, 2025

JimBobSquarePants commented Mar 26, 2025 •

edited

Loading

antonfirsov left a comment

antonfirsov Mar 26, 2025 •

edited

Loading

JimBobSquarePants Mar 27, 2025

antonfirsov Mar 28, 2025 •

edited

Loading

JimBobSquarePants Mar 28, 2025

antonfirsov Mar 28, 2025

V3 : Fix GIF, PNG, and WEBP Edge Case Handling #2882

V3 : Fix GIF, PNG, and WEBP Edge Case Handling #2882

Conversation

JimBobSquarePants commented Feb 7, 2025 • edited Loading

Prerequisites

Description

Copilot AI left a comment

Choose a reason for hiding this comment

antonfirsov commented Feb 25, 2025

JimBobSquarePants commented Feb 26, 2025

brianpopow commented Mar 3, 2025

JimBobSquarePants commented Mar 3, 2025

brianpopow commented Mar 3, 2025 • edited Loading

JimBobSquarePants commented Mar 3, 2025

brianpopow commented Mar 5, 2025

JimBobSquarePants commented Mar 6, 2025 • edited Loading

JimBobSquarePants commented Mar 12, 2025

brianpopow commented Mar 13, 2025

SpaceCheetah commented Mar 21, 2025 • edited Loading

JimBobSquarePants commented Mar 24, 2025 • edited Loading

antonfirsov left a comment • edited Loading

Choose a reason for hiding this comment

Config

EncodeGif_DefaultEncoder

release/3.1.x

PR

DecodeEncodeGif_DefaultEncoder

release/3.1.x

PR

antonfirsov Mar 26, 2025 • edited Loading

Choose a reason for hiding this comment

antonfirsov Mar 26, 2025

Choose a reason for hiding this comment

JimBobSquarePants Mar 26, 2025 • edited Loading

Choose a reason for hiding this comment

JimBobSquarePants commented Mar 26, 2025

JimBobSquarePants commented Mar 26, 2025 • edited Loading

antonfirsov left a comment

Choose a reason for hiding this comment

antonfirsov Mar 26, 2025 • edited Loading

Choose a reason for hiding this comment

JimBobSquarePants Mar 27, 2025

Choose a reason for hiding this comment

antonfirsov Mar 28, 2025 • edited Loading

Choose a reason for hiding this comment

JimBobSquarePants Mar 28, 2025

Choose a reason for hiding this comment

antonfirsov Mar 28, 2025

Choose a reason for hiding this comment

JimBobSquarePants commented Feb 7, 2025 •

edited

Loading

brianpopow commented Mar 3, 2025 •

edited

Loading

JimBobSquarePants commented Mar 6, 2025 •

edited

Loading

SpaceCheetah commented Mar 21, 2025 •

edited

Loading

JimBobSquarePants commented Mar 24, 2025 •

edited

Loading

antonfirsov left a comment •

edited

Loading

`EncodeGif_DefaultEncoder`

`release/3.1.x`

`DecodeEncodeGif_DefaultEncoder`

`release/3.1.x`

antonfirsov Mar 26, 2025 •

edited

Loading

JimBobSquarePants Mar 26, 2025 •

edited

Loading

JimBobSquarePants commented Mar 26, 2025 •

edited

Loading

antonfirsov Mar 26, 2025 •

edited

Loading

antonfirsov Mar 28, 2025 •

edited

Loading