1 px line on top of every image pasted into Firefox from paint.net

[Rick Brewster]

Welp, here we go again 🤔

 

I'll move the issue to the v5.1 milestone, hopefully we can reach clarity by then

[Rick Brewster]

3 hours ago, AndersM said:

I've attached a zip with two 16x16x32bit bitmaps in v4 BI_BITFIELDS format

 

Why v4? I was under the impression that only v1 (BITMAPINFOHEADER) and v5 (BITMAPV5HEADER) are relevant

[Rick Brewster]

FWIW, WIC adds the 3 masks when writing out a V5 bitmap/DIB. That's canonical enough for me.

[AndersM]

1 hour ago, Rick Brewster said:

Why v4? I was under the impression that only v1 (BITMAPINFOHEADER) and v5 (BITMAPV5HEADER) are relevant

That was just a conincidence. I just picked one of the file sets that demonstrate the problem. v3, v4 and v5 all have it.

 

I can read v1, v2, v3, v4, and v5 in BI_RGB and BI_BITFIELDS format but I only write v1 and v2 in BI_RGB format (since BI_BITFIELDS has no purpose in that version (because no alpha)), and I only write v3, v4, and v5 in BI_BITFIELDS format (since I need the alpha). v2 btw is an undocumented, unreleased format. It's only included for completeness.

For some reason the Windows shell only supports alpha for v4 and later.

Also, the Windows shell doesn't like the color table:

 

For the clipboard only v1 and v5 are relevant.

 

1 hour ago, Rick Brewster said:

FWIW, WIC adds the 3 masks when writing out a V5 bitmap/DIB. That's canonical enough for me.

Okay, but have you tried opening a v5 BI_BITFIELDS bmp file produced by WIC in, for example, MS Paint?

 

So far it appears that the clipboard expects a DIB with a color table but everything else expects one without. So far I haven't found a single application that can load the color table v4/v5 bmps correctly. Even online editors experience the problem (tested with both Firefox, Edge and Chrome).

[Rick Brewster]

33 minutes ago, AndersM said:

Okay, but have you tried opening a v5 BI_BITFIELDS bmp file produced by WIC in, for example, MS Paint?

That should include any 32-bit BMP saved by PDN for the last 5+ years.

[AndersM]

7 minutes ago, Rick Brewster said:

That should include any 32-bit BMP saved by PDN for the last 5+ years.

That doesn't really answer my question 🙂

I'm not using PDN so I haven't got any samples of the BMPs it produce.

 

Against better judgment I've now looked a bit more into this. As far as I can tell, when dealing with DIBs, many parts of Windows expect or produce a color table for BI_BITFIELDS DIBs - However not all. Notably, parts of the gdi, icm, and the imaging part of MS Paint, among others, expect a color table in v3 BI_BITFIELDS DIBs but explicitly not in v4 or v5. FWIW, this corresponds to my original implementation.

I have no idea how all these different parts manage to interoperate when they can't agree on the data format.

[Rick Brewster]

8 hours ago, AndersM said:

I think I'm going crazy.

 

I'm getting similar results. If I use WIC to save a BMP, and then skip past the BITMAPFILEHEADER and place the remaining bytes on the clipboard, and paste back into various apps:

• Paint.NET: Works fine, obviously. WIC can handle its own output.
• mspaint: Refuses to paste the image
• GIMP: No transparency, and shifted right by 3 pixels
• Krita: Includes transparency, still shifted right by 3 pixels

This is for a BITMAPV5HEADER bitmap w/ BI_BITFIELDS.

[Rick Brewster]

It would appear that BMP and DIB, despite being the same thing, are not actually handled uniformly.

[Rick Brewster]

So from what I can tell for BMP storage, you include the 3 bitmasks when doing BITMAPV5HEADER + BI_BITFIELDS. This is with straight alpha.

 

When copying to the clipboard as a CF_DIBV5, you do not include the 3 bitmasks when doing BITMAPV5HEADER + BI_BITFIELDS. This is also with straight alpha.

 

Chrome does it differently. For an image with transparency (e.g. the forum logo, https://content.invisioncic.com/r125076/monthly_2020_09/getpaint_whitetext.png.9b52024e6a4fb3fcc770ebb1beb86df7.png), it will copy to the clipboard specifying BI_RGB, and 32-bits, and then it will use premultiplied pixels. This also seems to be Firefox's strategy.

 

This seems to be the de facto spec. For whatever reason that's what other imaging apps are doing.

 

Ergo, PDN's current implementation is, for lack of a better word ... correct.

[Rick Brewster]

When copying images with transparency from Krita or GIMP, they are BITMAPV5HEADER, do specify BI_BITFIELDS, but do not include the 3 masks. And WIC can't decode them! (after inserting a BITMAPFILEHEADER at the start)

 

mspaint sorta side-steps this by copying only a CF_DIB and a PNG. It does not copy a CF_DIBV5 to the clipboard. I'm using the latest version with transparency and layers support.

 

So, again, apps should prefer PNG if it's on the clipboard. Include DIB/DIBV5 for the sake of legacy apps, but don't waste your time trying to make sure it's compatible with all other apps because that just isn't possible.

[Rick Brewster]

1 hour ago, Rick Brewster said:

It would appear that BMP and DIB, despite being the same thing, are not actually handled uniformly.

 

BTW this really does seem to be the clincher. BMP (on disk) and DIB (in memory, or at least on the clipboard) just aren't treated the same, even though they should be.