Mercury13

https://github.com/Mercury13/clipboard-demo Here’s program I played with. Strange: Windows always created LONG DIBv5, but if you copy to clipboard, it correctly converts SHORT.

Strange. Windows itself always creates LONG DIBv5. But correctly converts SHORT DIBv5, and badly long.

Managed to check. What if WINDOWS AUTO-CONVERTS old DIB to DIBv5 with those 12 bytes? If Windows is not an argument, what’s an argument?

I mean, for some reason this software REQUIRES these twelve bytes and shifts image data: XnView WinXP Clipboard viewer Firefox and Paint Tool SAI, as someone said This software CREATES these twelve bytes: Win10 screenshot feature Maybe not everyone rides the wrong lane, but you do, as Russian joke says?

Windows is the ultimate argument when we are writing for Windows, right? Two standard features of Windows, PrintScreen and Clipboard Viewer, DO ADD or DO REQUIRE these 12 bytes. I found another argument. Maybe I’ll try, but not today, I’m a bit sick and keeping energy for my main job. Windows automatically synthesizes other formats, so I’ll try to copy as DIBv5 and paste as DIB. If this DIBv5 gives incorrect DIB, or Windows refuses to convert at all — what’s else?

I said Skia,but it’s Chromium. https://chromium.googlesource.com/chromium/src/+/master/ui/base/clipboard/clipboard_win.cc

Here’s more of Skia logic. I don’t see Skia’s WRITING code for now, but this is Skia’s READING code. switch (bitmap->bmiHeader.biBitCount) { case 1: case 4: case 8: color_table_length = bitmap->bmiHeader.biClrUsed ? bitmap->bmiHeader.biClrUsed : 1 << bitmap->bmiHeader.biBitCount; break; case 16: case 32: if (bitmap->bmiHeader.biCompression == BI_BITFIELDS) color_table_length = 3; break; case 24: break; default: NOTREACHED(); }

Also, as I said, old WinXP’s CLIPBRD.EXE expects those 12 bytes. But Clipboard Viewer is not critical software and does not check for buffer overruns, unlike Firefox.

Windows’ screenshot function DOES INSERT these 12 bytes. I’ll copy a bit of pure white using W10’s Win+Sh+S… If Windows does, why shouldn’t you? Total data length = 0x130 Size = 0x7C Width = 6 Height = 7 Planes = 1 Bitcount = 32 Compression = BITFIELDS SizeImage = 0xA8 XPelsPerMeter = 0 YPelsPerMeter = 0 ClrUsed = 0 ClrImportant = 0 RedMask = 0xFF0000 GreenMask = 0xFF00 BlueMask = 0xFF AlphaMask = 0 CsType = 'sRGB' (bytes reversed, write as C multi-char constant) Endpoints = all zeros Gamma = all zeros Intent = IMAGES ProfileData = 0 ProfileSize = 0 Reserved = 0 [dword 0x7C] = 0xFF0000 [dword 0x80] = 0xFF00 [dword 0x84] = 0xFF And then 0xA8 FF’s 0x7C + 0xA8 + 0x0C = 130

If I were involved for myself, I’d just write “Paint.NET creates BI_BITFIELDS w/o colour table, check for it.”

You, in Paint.NET land. It’s not treated as header but as colour table consisting of three entries.

Who does not copy in BI_BITFIELDS for himself but expects those 12 bytes from other software… WinXP’s CLIPBRD.EXE XnView

Other software I tested, e.g. GIMP or many-years-old Photoshop, use RGB DIBv5, and for transparent imagery they utilize other formats, e.g. Metafile.

So, the problem is those twelve bytes at offset 7C…87 of DIBv5. Should we insert them? Who inserts… Windows’ “Print Screen” function Skia, by code if (bitmap->bmiHeader.biCompression == BI_BITFIELDS) color_table_length = 3; Documentation states: BI_BITFIELDS: The bitmap is not compressed, and the color table consists of three DWORD (defined in [MS-DTYP] section 2.2.9) color masks that specify the red, green, and blue components, respectively, of each pixel. This is valid when used with 16 and 32-bits per pixel bitmaps. Maybe you forgot those bytes rather than they inserted erroneously?