Skip to content
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

#718 #730: Add Gray8 and Gray16 Pixel Formats and clean up IPixel #729

Merged
merged 34 commits into from
Oct 23, 2018

Conversation

jongleur1983
Copy link
Contributor

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 matches 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

Implements Pixel formats Gray8 and Gray16.
Where I knew how to do it I provided optimized conversion methods, where not I used the "fallback" strategy to convert from and to Vector4, as it's done for many other implementations as well.

Unit tests are based on some of the other Pixel formats tests. Not sure this is seen as sufficient though, please tell me if not.

I guess I have to squash commits again, but for review the individual commits may help so I'm happy to do so after a first review.

Copy link
Member

@JimBobSquarePants JimBobSquarePants left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've started a review but I can see quite a lot of places where the maths are incorrect. It's probably quicker for me to push the changes to the code myself so am gonna jump in. Hope you don't mind!


/// <inheritdoc/>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public void ToGray8(ref Gray8 dest) => dest.PackFromScaledVector4(this.ToScaledVector4());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be optimized.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public void PackFromRgba32(Rgba32 source)
{
this.PackedValue = Pack(source.R, source.G, source.B);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and others is incorrect. Will lead to a packed value of 255.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public void ToRgb48(ref Rgb48 dest)
{
ushort gray = (ushort)(this.PackedValue * 255);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* 257

/// <param name="b">Blue value of the color to pack.</param>
/// <returns>The <see cref="byte"/> containing the packed value.</returns>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
private static byte Pack(float r, float g, float b)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only works with Vector4 but is being used for Rgba32 etc.

@JimBobSquarePants
Copy link
Member

I'm gonna do #730 at the same time otherwise we're writing code we'll immediately delete.

@JimBobSquarePants JimBobSquarePants changed the title #718: Add Gray8 and Gray16 Pixel Formats WIP #718 #730: Add Gray8 and Gray16 Pixel Formats and clean up IPixel Oct 9, 2018
@JimBobSquarePants
Copy link
Member

@jongleur1983 Ok. So I've fixed up all the pixels formats and commented out all the old tests.

I need to do two things now to complete this PR:

  1. Add a new suite of tests to cover IPixel functionality
  2. Add optimized overloads for the PixelOperations methods.

@JimBobSquarePants
Copy link
Member

Got four tests failing due to ToString change in Rgba32 as the reference image path depended on original name. We should update that. Perhaps hex?

https://ci.appveyor.com/project/six-labors/imagesharp/builds/19386791/job/x9ru3njufhn9ec6j/tests

@antonfirsov
Copy link
Member

Yeah hex is better for this purpose

@codecov
Copy link

codecov bot commented Oct 15, 2018

Codecov Report

Merging #729 into master will decrease coverage by 0.95%.
The diff coverage is 83.6%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #729      +/-   ##
==========================================
- Coverage    89.3%   88.34%   -0.96%     
==========================================
  Files         973      982       +9     
  Lines       42976    41592    -1384     
  Branches     3047     3126      +79     
==========================================
- Hits        38381    36746    -1635     
- Misses       3913     4129     +216     
- Partials      682      717      +35
Impacted Files Coverage Δ
...geSharp.Tests/PixelFormats/NormalizedByte4Tests.cs 100% <ø> (ø) ⬆️
tests/ImageSharp.Tests/PixelFormats/Short2Tests.cs 100% <ø> (ø) ⬆️
...eSharp.Tests/PixelFormats/NormalizedShort2Tests.cs 100% <ø> (ø) ⬆️
tests/ImageSharp.Tests/PixelFormats/Argb32Tests.cs 100% <ø> (ø) ⬆️
tests/ImageSharp.Tests/PixelFormats/Bgr565Tests.cs 100% <ø> (ø) ⬆️
.../ImageSharp/PixelFormats/Rgba32.PixelOperations.cs 100% <ø> (ø) ⬆️
tests/ImageSharp.Tests/PixelFormats/Short4Tests.cs 100% <ø> (ø) ⬆️
...mageSharp.Tests/PixelFormats/UnPackedPixelTests.cs 100% <ø> (ø) ⬆️
...ests/Processing/Transforms/AffineTransformTests.cs 98.48% <ø> (-0.04%) ⬇️
tests/ImageSharp.Tests/Numerics/RationalTests.cs 100% <ø> (ø) ⬆️
... and 134 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f5ebbb...cd543b2. Read the comment docs.

@JimBobSquarePants
Copy link
Member

Much happier with this now. The structure has much greater conformity and all IPixel operations are covered in both singular and bulk forms.

Gotta fix up the ToString() methods to use invariant culture but I'll wait til the other PR's come in first to drop NetStandard 1.1

@antonfirsov
Copy link
Member

antonfirsov commented Oct 17, 2018

Ok, actually this might be good, I haven't noticed the new optimized bulk implementations!

So never mind my comment regarding dp.PackFromScaledVector4(sp.ToScaledVector4());! Gonna have a second look on Thursday.

@JimBobSquarePants
Copy link
Member

@antonfirsov Yeah, all the IPixel conversions have optimized bulk implementations so there should be no performance loss. It should actually be faster in some cases than before.

@antonfirsov
Copy link
Member

@JimBobSquarePants in this benchmark I emulated a scenario which is similar to the ToRgba32() stuff happening in PNG encoder, and certain processors (eg. Binarization, Dithering).

It turns out, that even in these cases the retval version is significantly slower.

Also benchmarked ToVector4() - same stuff, with less difference. I can't really explain this, but we should change to a CopyTo(ref ...) style API in both cases.

The question is when? We have two options:

  1. Change it in this PR, open issue for ToVector4(). Milestone: RC1 (API change)
  2. Merge this PR, open issue for both ToRgba32() and ToVector4(). Milestone: RC1 (API change, perf regression!)

@JimBobSquarePants
Copy link
Member

JimBobSquarePants commented Oct 18, 2018

@antonfirsov Those results are extraordinary, I'm very surprised!

Let's do it here now. A new PR will be another very large one again probably too large to digest. We know where we are here and can review knowing exactly what we are looking at having recently worked on the files.

ScaledVector4 will have to be updated also.

@antonfirsov
Copy link
Member

antonfirsov commented Oct 18, 2018

One possible explanation is that JIT is not capable for Return value optimization in most cases.

Do you mean also finishing up the Vector4 stuff here?` Should/can we split the work somehow?

Edit:
Just noticed your edit on Vector4

@JimBobSquarePants
Copy link
Member

I was tempted to do it all here but for sanities sake lets do Rgba32 here and immediately raise an issue for next priority for Vector4. We don't want to be blocking any open PR's

@antonfirsov
Copy link
Member

@JimBobSquarePants my feeling is that it would be much simpler to merge this as is, right after #742 and carry out all my proposed API changes together in a new PR.

@JimBobSquarePants
Copy link
Member

@antonfirsov works for me! 👍

@antonfirsov
Copy link
Member

Is something wrong with GitHub at the moment?

The status checks are not being updated + the git changelog I see with my client is out of sync with the stuff presented on GitHub web.
image

1 similar comment
@antonfirsov
Copy link
Member

Is something wrong with GitHub at the moment?

The status checks are not being updated + the git changelog I see with my client is out of sync with the stuff presented on GitHub web.
image

@antonfirsov
Copy link
Member

@JimBobSquarePants any idea how to ping the CLA assistant? Pressing "Recheck PR-s" on it's UI did not help.

@antonfirsov
Copy link
Member

OK, it seem there are still issues with service availability, let's check again after a few hours.

@JimBobSquarePants
Copy link
Member

@antonfirsov Github's having all sorts of issues just now.

@JimBobSquarePants JimBobSquarePants merged commit d65cf67 into SixLabors:master Oct 23, 2018
antonfirsov pushed a commit to antonfirsov/ImageSharp that referenced this pull request Nov 11, 2019
SixLabors#718 SixLabors#730: Add Gray8 and Gray16 Pixel Formats and clean up IPixel
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants