BMP image does not read correctly anymore. (Issue #24219)
dsa-t
A specific BMP image does not read correctly anymore.
Here's how the image is supposed to look like:
Most colors are replaced with transparency when loaded by wx and saved as png:
Original table.bmp and the result saved in png is in the archive:
image.zip
Platform and version information
- wxWidgets version you use: 3.3 (8967bed)
- wxWidgets port you use: wxGTK
- OS and its version: Linux Mint 21.1
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
Can be seen with the image sample on MSW, so not GTK-specific.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
AliKet
Can be seen with the
imagesample on MSW, so not GTK-specific.
The same with wxQt! so this is definitely not GTK-specific.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Randalphwa
Placing the BMP file into the richtext sample just shows a black box (run on Windows 11). The BMP does display correctly when loaded into Windows 11 Paint. It does not display correctly in Affinity Photo 2, Affinity Designer 2, or Topaz Sharpen AI. It does display correctly in HTML Help Image Editor which has not been updated since 1999 -- so while the BMP format might be unusual enough to throw off the commercial products I tried it on, it's a format that was at least understandable 25 years ago.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
A specific BMP image does not read correctly anymore
The image by the OP is on Windows displayed by the image sample in grayscale (i.e., incorrectly) from wxWidgets 3.0.5 to the (almost) current GIT master (tested also many versions in between, including 3.2.x and bunch of 3.1.x), so it is not a recent thing, at least on MSW.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
so it is not a recent thing, at least on MSW.
You're right. I was looking at wrong data.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
Does the image have alpha or not?
It doesn't seem like it's supposed to have alpha. GIMP doesn't import an alpha channel with it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
FWIW, I have tried a bunch of programs on Windows 10 and they all displayed the image in color:
FireFox and Chrome, GIMP, Corel PhotoPAINT, Inkscape, IrfanView, Total Commander, Paint, Paint 3D, Photos, Snip&Sketch, Libre Office and Microsoft Office.
The only program that displayed the image with transparency was web-based Photopea.
So I think, the problem is not with the image but wxWidgets. I also tried the image sample from wxWidgets 2.8.12 and it has issues to display the image at all, so...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
The file loads correctly on Windows using wxBitmap::LoadFile(), which uses WIN32 LoadFile(). I think the issue here is that despite the depth being 32, Windows (and most other software) only uses the RGB values and not the alpha. Maybe the alpha is only used if the file has an "extended" header, like BITMAPV4HEADER.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
Actually, I think the alpha is only used if BITMAPINFOHEADER.biCompression == BI_BITFIELDS.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.