New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resizing operation throws InvalidOperationException with exotic image resolution #1625
Comments
@antonfirsov you were right, Problem lies inside processor itself and who knows what other proccessors might fail due the same problem with allocations. |
ImageSharp/src/ImageSharp/Processing/Processors/Transforms/Resize/ResizeWorker.cs Lines 76 to 79 in 993f96e
I don't think that providing such internal detail about allocator is a good thing, memory user should work with size of the given memory, not with some configuration value from entierly different class This is error prone and introduce dependency from underlying implementation. Anyway, even if logic is correct, code fails on calling GetSingleSpan() on Buffer2D which is strange, shouldn't this code allocate P.S. |
@br3aker nice catch, thanks for the report! Repro confirmed. I hope I will be able to look into this next week, this one is completely busy with other stuff. |
@br3aker resizing is one of the more complicated processors, but it's just based on convolution in the end, as are things like blur, sharpen, and edge detection. This is probably the best intro to the math behind resizing I've seen: http://entropymine.com/imageworsener/resample/ |
@saucecontrol thanks a lot! Will definetely take a look. |
We'll need to look at this again now the memory allocator works differently. |
@antonfirsov It appears to me that we can ensure the allocation is contiguous now via the new ImageSharp/src/ImageSharp/Memory/MemoryAllocatorExtensions.cs Lines 26 to 32 in bab74dc
Passing ImageSharp/src/ImageSharp/Processing/Processors/Transforms/Resize/ResizeWorker.cs Lines 88 to 91 in bab74dc
We could then drop the calculation, and property here and just enforce a 1MB limit internally. ImageSharp/src/ImageSharp/Processing/Processors/Transforms/Resize/ResizeWorker.cs Lines 76 to 79 in bab74dc
Is that correct? |
@JimBobSquarePants yeah that would solve the problem, I will file a PR to fix this soon. Note that this is a corner case, you can't trigger it with sane code, especially hard with the new API. |
DEBUG
andRELEASE
modeDescription
Custom debug logs from
MemoryGroup<T>.Allocate(...)
call during steps stated below:Last allocation from log allocates 150 Vector4 elements with a stride of 10 elements which is done by allocating 3 separate buffers of 60 elements each which fullfils requested "contiguous chunks of 10 elements each", so far so good.
Real problem lies inside ResizeWorker class:
ImageSharp/src/ImageSharp/Processing/Processors/Transforms/Resize/ResizeWorker.cs
Lines 117 to 118 in 993f96e
Although comment states that buffer is ensured to be contiguous it's not:
ImageSharp/src/ImageSharp/Processing/Processors/Transforms/Resize/ResizeWorker.cs
Lines 88 to 91 in 993f96e
Allocate2D only ensures that requested memory is aligned by at least chunks of
width
parameter:ImageSharp/src/ImageSharp/Memory/MemoryAllocatorExtensions.cs
Lines 25 to 35 in 993f96e
Which is what happened in logs, ResizeWorker requested 10 strides of 15 elements with alignment of 15.
Atm given Buffer2D API doesn't provide any way to ensure that requested memory occupies single contiguous buffer but I suppose it should be something like this:
Steps to Reproduce
Use this code snippet:
With this 10x10 pixels plain black png image:
https://user-images.githubusercontent.com/20967409/117883361-fdb01e80-b2b3-11eb-850f-10c66309430d.png
Yes, it can be broken even with current default config allocator but with a bit more extreme example:
With this 1x4096 pixels plain black png image:
https://user-images.githubusercontent.com/20967409/117890174-56d08000-b2bd-11eb-93f3-ad625787f0be.png
The text was updated successfully, but these errors were encountered: