-
-
Notifications
You must be signed in to change notification settings - Fork 851
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
Fix #2518 #2519
Merged
Merged
Fix #2518 #2519
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
43c542b
OilPaint benchmark
antonfirsov 6d6833e
fix #2518
antonfirsov 075d05f
Update OilPaintingProcessor{TPixel}.cs
JimBobSquarePants 99771d6
clamp the vector to 0..1 and undo buffer overallocation
antonfirsov ac0c1f9
throw ImageProcessingException instead of clamping
antonfirsov 918ea1b
Merge branch 'main' into fix-2518
antonfirsov File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
// Copyright (c) Six Labors. | ||
// Licensed under the Six Labors Split License. | ||
|
||
using BenchmarkDotNet.Attributes; | ||
using SixLabors.ImageSharp.PixelFormats; | ||
using SixLabors.ImageSharp.Processing; | ||
|
||
namespace SixLabors.ImageSharp.Benchmarks.Processing; | ||
|
||
[Config(typeof(Config.MultiFramework))] | ||
public class OilPaint | ||
{ | ||
[Benchmark] | ||
public void DoOilPaint() | ||
{ | ||
using Image<RgbaVector> image = new Image<RgbaVector>(1920, 1200, new(127, 191, 255)); | ||
image.Mutate(ctx => ctx.OilPaint()); | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately,
ToScaledVector4
doesn't guarantee that the vector will be clamped to0..1
since a pixel implementation is free to return anything. (In factRgbaVector
doesn't clamp!)With clamping I was able to undo the buffer overallocation in 99771d6. (Which was in fact ad-hoc since
RgbaVector
can hold an arbitrary high value, way above 255.)I think the PR should be good now if you are also fine with the changes @JimBobSquarePants .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn’t we fix RgbaVector? ScaledVector is supposed to guarantee 0…1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just had a look at several of our pixel formats. None of the sanitize the range in construction. We should fix that across the board.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder which are the pixel types where
ToScaledVector4()
could go out of range? To me it looks like it can happen only with floating point ones (RgbaVector
,HalfVector2|4
,HalfSingle
...) Do you see any other ones?Sanitizing in the constructor is insufficient since (1) there are public fields/properties to manipulate the values (2) low-level
MemoryMarshal.Cast
-like manipulation is completely normal when working with pixel buffers and it can also push values out of range. If we want a guarantee thatToScaledVector4()
implementations always return values in0..1
, clipping should happen inToScaledVector4()
.However, even if guarantee this in our own pixel types, arbitrary user pixel types can still potentially violate the contract. If it only leads to an
IndexOutOfRangeException
, we can blame it on the user. However, if we have unsafe indexing depending on the the values returned fromToScaledVector4()
(like we used to do in OilPaint) we have a serious bug in the processor. We may have a similar problem here:ImageSharp/src/ImageSharp/Processing/Processors/Normalization/AutoLevelProcessor{TPixel}.cs
Lines 151 to 153 in e81efa3
My recommendation is to revisit these processors before doing anything else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the pixel formats accepting a
float
lack sanitation soShort2
,Short4
, and theNormalizedXX
variants would be on the list also.Scaled vector shouldn't clip. It should normalize the scale of the min max values of the pixel format. The mutability of the pixel formats makes sanitation difficult but as you say, avoiding unnecessary unsafe code turns a trivial exception to a serious one so we should definitely review and fix any processors that could be affected.
Regarding this PR. That clamp is going to hurt performance and should be unnecessary given the correct
Vector4
range. I'd say we revert it and merge before continuing to sanitize the processors.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See ac0c1f9. With aéé the confusion this PR started with, it would make sense to squash on merge.