Repository navigation
Added Argb IPackedPixel - #33
Conversation
JimBobSquarePants
left a comment
JimBobSquarePants
left a comment
There was a problem hiding this comment.
This is a great PR! happy to merge it. Thanks!
| @@ -0,0 +1,3 @@ | |||
| [*.cs] | |||
| Assert.Equal(bgra, new byte[] { 0, 0, 0, 128 }); | ||
| } | ||
|
|
||
| [Fact] |
| /// <returns>The <see cref="uint"/></returns> | ||
| static uint Pack(float x, float y, float z, float w) | ||
| { | ||
| var value = new Vector4(x, y, z, w); |
There was a problem hiding this comment.
I don't use var myself but I can clean this up after the merging the PR so don't worry about it.
There was a problem hiding this comment.
Oh, sorry, didn't see enough of the rest of the code to not use it (I do use var)!
There was a problem hiding this comment.
why not using var? 😄 The rule I use these days is: use var by default, unless the type cannot be easily inferred from reading the code. It makes the code more maintainable - for instance if I change from an IEnumerable to IList, etc, I don't need to update all the places, it kinda just works.
There was a problem hiding this comment.
@olivif What is the resultant type of x in this bit of code?
var x = (byte)1 + (byte)2;
I'm sure you know this already but it's an int due to implicit casting since bytes don't have an + operator. (This is the simplest example I could think of as an easy mistake to make using var)
I work with streams a lot and I've lost count of the amount of times that the wrong value has been passed to a BinaryWriter due to the use of var. That's always a nightmare to debug!
I know it's more common to use now but in certain critical codebases like the Roslyn compiler it's still banned.
I honestly believe that it's having a negative effect on modern programming. Devs aren't learning their types nor the framework properly as a result and are being careless, using var mostly because they don't know what the return type of a method should be.
There was a problem hiding this comment.
@JimBobSquarePants this is super interesting, I've actually never run into these type problems due to var, thanks for sharing 😄 . I understand the perils now, up until now it was just the maintainability argument for me, but now I see how it could go wrong.
I honestly believe that it's having a negative effect on modern programming. Devs aren't learning their types nor the framework properly as a result and are being careless, using var mostly because they don't know what the return type of a method should be.
I fully agree here. I was fortunate enough to write a lot of C++ before coming to C# but I realize that might not be the norm these days.
There was a problem hiding this comment.
You're better than I then! I tried C++ once..... Nope, too hard! 😄
There was a problem hiding this comment.
Haha! Well, it was great at the time and definitely learnt a lot. Would I go back to unmanaged without a really good reason? Probably not 😄
|
Excellent! Thanks for this 💯 |
|
Thank you for making the library happen! 😄 |
Apply SharedInfrastructure, introduce shared guards
Apply SharedInfrastructure, introduce shared guards
Apply SharedInfrastructure, introduce shared guards
The chroma search has to predict from the luma winner, so the reference encodes the luma plane again at the start of av1_rd_pick_intra_sbuv_mode. The port reconstructed at the end of the candidate mode search instead and then let the winner transform refinement copy cached samples over the plane, so no later pass re-ran the transform and an empty luma transform block never returned to DCT_DCT. Reconstruct once more after the refinement, and reset the coded transform type of an empty luma block where encode_block_intra resets it. At bike512-420-8-q64-s6 the 8x8 at sample (224,24) now leaves the same four transform blocks as the reference, with the bottom right one holding one coefficient instead of nothing. The block to its right predicts at 135 degrees from that column and now measures the same distortions as the reference, 5724 at depth 0 and 4486 at depth 1, and picks the same transform depth. The first differing block moves 126 blocks later, from sb(3,0) SixLabors#33 to sb(0,1) SixLabors#11, and 1452 blocks differ where 1557 did.
3 participants
Adds support for ARGB packed pixels.