In short, I tried to generate a QR code in Gamma. Followed the code from github. And found a strange bug in the resulting textures. At first I thought I was doing something wrong, but then it turned out that Skia’s node converts bytes correctly. And the buggy effect disappears at value 4 (but the texture resolution is different)
@bjoern, good one to ask!) Thank you for pointing that out.
Sometimes you just don’t have the time to keep track of what libraries are out there, so you resort to the old tried and tested method of building your own solution based on your favourite Nuget.
But to be honest, this is a different problem. Something unexpected with memory. Maybe it’s something serious, and I’ve decided to describe this problem - in case it shows up somewhere else. It’s not about QR codes.
in your screenshot we see that the first tooltip has RGBA while the others have RGB only. so apparently the source actually has an alpha channel but your attempt going via Bitmap does not respect that.
@joreg I can remove MemoryStream for the moment and the problem remains. Are you saying that bytes returned by QRCoder are suitable for SKImage but not for other nodes? We should call this issue something else
QRCodeGenerator qrGenerator = new QRCodeGenerator();
QRCodeData qrCodeData = qrGenerator.CreateQrCode("The text which should be encoded.", QRCodeGenerator.ECCLevel.Q);
BitmapByteQRCode qrCode = new BitmapByteQRCode(qrCodeData);
byte[] qrCodeAsBitmapByteArr = qrCode.GetGraphic(20);
//From here on, you can implement your platform-dependent byte[]-to-image code
//e.g. Windows 10 - Full .NET Framework
Bitmap bmp;
using (var ms = new MemoryStream(qrCodeAsBitmapByteArr))
{
qrCodeImage = new Bitmap(ms);
}
right, it has nothing to do with the memorystream. the data coming from the QRCoder is apparently encoded image data, meaning they come with a header. ie. you can write those bytes in a file and if you know what format (bmp, png,…) give the file that ending and you have a valid file. does the tooltip show something after Bitmap.Create?
Then the question remains, but it is worth rephrasing it. It turns out that the only way to convert BMP byte data to Gamma is Skia? And I have basically done everything right?
Because the Bitmap node is not an encoder, but basically just presents bytes to be read as a bitmap image?
It doesn’t contain an alpha channel as far as I can tell.
Bytes for exactly three RGB channels, no A. But with a little extra - obviously because of the header. The alpha channel in the case of Skia is taken by definition, most likely it “appears”, not calculated from the data. I could be wrong, but that’s how I saw it - exactly 3 bytes per pixel plus bytes for the header.
I tried saving the bytes as you suggested - it opens as a normal BMP. If you open it as a binary file, the header is clearly visible.
In this case I don’t understand what the problem is. Should it be converted or not?
huh, you’re right. i was following the wrong lead because the “FromEncodedData” node (that worked all along) was returning BGRA, but that’s actually the case because there is not SKImage in RGB-only format.
so, turns out there was indeed a bugger in our own RGB to RGBA conversion code used in the ToImage node. thanks for insisting, fixed for latest preview.