Alpha value clipboard bug

[pagefault]

Hi, i ran into a bug while using the latest 4.0 build. I wanted to save a screenshot from the game War Thunder so I pressed my "print screen" button and pasted into Paint.Net. The resulting image however has wrong alpha values in a lot of places. A screenshot should naturally have alpha values of 255 everywhere. GIMP has no problem when I paste the screenshot into it. This is how it looks in Paint.Net:

Edited June 28, 2014 by pagefault

[BoltBait]

If you have my plugin pack installed, please go into your game and press PrtSc and then use my Effects > Fill > From Clipboard.

Does it give the same error?

[Rick Brewster]

Actually it probably has all the correct alpha values. Paint.NET doesn't know that it's a "screenshot," and your game or Windows is probably just filling the clipboard from whatever's in the fullscreen Direct3D buffer that it's using. Paint.NET isn't just randomly deciding what alpha values to use, it's doing exactly what it was told to do.

 

Create a new layer, move it to the bottom, and fill it with black. Then flatten.

[pagefault]

If you have my plugin pack installed, please go into your game and press PrtSc and then use my Effects > Fill > From Clipboard.

Does it give the same error?

yes, same error.

 

Actually it probably has all the correct alpha values. Paint.NET doesn't know that it's a "screenshot," and your game or Windows is probably just filling the clipboard from whatever's in the fullscreen Direct3D buffer that it's using. Paint.NET isn't just randomly deciding what alpha values to use, it's doing exactly what it was told to do.

 

Create a new layer, move it to the bottom, and fill it with black. Then flatten.

I guess you're right. But why doesn't gimp have this problem then?

[Rick Brewster]

Because they probably don't try to support alpha channel via paste? I don't know, that's just a guess. I'm not even sure that I'd classify this as a bug ... The game is putting alpha on the clipboard and paint.net is using it. The clipboard is a cantankerous beast. I fix paste for one scenario and it breaks for two others.

[midora]

You may use a tool like DaDRoots which shows the elements on the clipboard and provide a screenshot of the tool here.

If there is a CF_DIBV5 then select it first.

[Rick Brewster]

PNG has higher priority, since it transmits alpha faithfully and unambiguously. Edit: This is no longer the case, since it broke other things. My comment above, "I fix paste for one scenario and it breaks for two others." was prophetically correct ...

 

Even then, CF_DIBV5 can be used to transmit alpha. It's just not as good since I have to use heuristics to determine what kind of alpha. (accidentally all zeros? okay I'll substitute 255's. is it premultiplied or straight? etc)

[pagefault]

You may use a tool like DaDRoots which shows the elements on the clipboard and provide a screenshot of the tool here.

If there is a CF_DIBV5 then select it first.

I don't know how to use this tool, but is this helpful? http://i.imgur.com/2OcQXqd.jpg

[midora]

The shot looks like expected.

On the clipboard there are three dataobjects available. Two of them may be created by auto expansion.

 

CF_BITMAP is hardware dependent and not used normally.

CF_DIB is one of the oldest format of a D)evice I)ndependent B)itmap. It may already be 32bit but no ABGR. Still sometimes it is misused to transport alpha.

CF_DIBV5 is a DIB which may containt an alpha channel. Lets have a look to your data in DIBV5:

typedef struct {
  DWORD        bV5Size;				00  0000007C  Header size 0x7C
  LONG         bV5Width;			04  00000780  1'920
  LONG         bV5Height;           08  00000438  1'080 (bottom up bitmap)
  WORD         bV5Planes;           0C  0001      Must be 1
  WORD         bV5BitCount;         0E  0020      32 bits per pixel
  DWORD        bV5Compression;      10  00000003  BI_RGB
  DWORD        bV5SizeImage;        14  007E9000  8'294'400 bytes
  LONG         bV5XPelsPerMeter;    18  00000000  Not set
  LONG         bV5YPelsPerMeter;    1C  00000000  Not set
  DWORD        bV5ClrUsed;          20  00000000  No color table entries 
  DWORD        bV5ClrImportant;     24  00000000  No important entries
  DWORD        bV5RedMask;          28  0000FF00  R Channel yes
  DWORD        bV5GreenMask;        2C  00FF0000  G Channel yes
  DWORD        bV5BlueMask;         30  FF000000  B Channel yes
  DWORD        bV5AlphaMask;        34  00000000  A-channel no (but not relevant for BI_RGB)
  DWORD        bV5CSType;           38  73524742  sRGB
  CIEXYZTRIPLE bV5Endpoints;        3C  ...       36 Bytes
  DWORD        bV5GammaRed;         60  00000000
  DWORD        bV5GammaGreen;       64  00000000
  DWORD        bV5GammaBlue;        68  00000000
  DWORD        bV5Intent;           6C  00000004  LCS_GM_IMAGES (Perceptual)
  DWORD        bV5ProfileData;      70  00000000
  DWORD        bV5ProfileSize;      74  00000000
  DWORD        bV5Reserved;         78  00000000
} BITMAPV5HEADER;                   7C

So it tells 32 bit but no alpha channel. This is the typical case were you should set the whole alpha channel to opaque to be on the safe side. Even if some people may complain that they lost alpha information.

 

Rick: I'm completely happy that PNG is preferred and this should not change. But there are not a lot of tools placing png on the clipboard. So simplest would be in all DIB cases to set the alpha channel to opaque. (3.5.11 did this?)

I thougth part of your motivation to add png was to remove the pixel data from PaintDotNet.Rendering.MaskedSurface on the clipboard. So without using more space you could exchange transparent data with other applications.

 

pagefault: Luckily there are several easy ways to set the alpha channel to opaque. I.E. with the Color Matrix plugin.