png file is garbled, Mac OS X

[justjoheinz]

I use allegro 5.2.9.1 (built by brew) on a Mac OS X M1 architecture. Libpng is 1.6.42.

I have a file (attached) which according to file is :

> file a10000.png                     
a10000.png: PNG image data, 64 x 64, 16-bit/color RGBA, non-interlaced

Using https://github.com/liballeg/allegro5/blob/master/examples/ex_bitmap_file.c to render this image the output is garbled.

If I do

> convert a10000.png -depth 8 a10000.png
> file a10000.png                     [13:15:09]
a10000.png: PNG image data, 64 x 64, 8-bit gray+alpha, non-interlaced

the output is ok

[pedro-w]

Would be useful to know if this is MacOS only or Allegro in general (guessing 16-bit pngs are not supported?)

[lockie]

The very same image is displayed properly on both Linux and Windows.

[pedro-w]

Alright,

allegro5/addons/image/macosx.m

Lines 53 to 55 in 8575e37

	int bits = [bitmap_rep bitsPerPixel];
	int samples = bits / 8;
	ALLEGRO_DEBUG("Read image of size %dx%dx%d\n", w, h, bits);

appears to be wrong; it's assuming 8 bits per channel, so that number of samples per pixel = number of bits per pixel / 8. In the example png, bitsPerPixel is 64, i.e. 4 samples of 16 bits each, will be incorrectly calculated as 8 samples of 8 bits each.
There may be other errors subsequent to this.

[pedro-w]

At the moment we're loading an NSImage then extracting its first NSImageRep which we hope is really an NSBitmapImageRep.
This class represents many different bitmap variants - planar or intermingled, premultiplied or not, with up to 5 channels, each up to 32 bits each. Allegro converts this to an ALLEGRO_BITMAP of type ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE but it doesn't handle all possible variants. Doing that would be possible but probably quite tedious, especially as most variants would be rare in practice.
Options I think are

• Write that code for all variants
• Error if it's not a 'common' variant
• Investigate CoreGraphics
• Draw to an intermediate context
• Use libpng et al (like Linux does, I assume)

I don't know anything about CoreGraphics but I saw Apple's docs suggesting it should be used if image manipulation was being done.
The 'intermediate context' idea is to create a Cocoa graphics context backed by a fixed bitmap format (ie. the equivalent of ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE) and just draw the NSImage into it, letting Cocoa do all the format changing. I think this should work but can't say if it would be too slow.

@SiegeLord has there been previous discussion on this, I can't believe this issue has only surfaced in 2024!

[SiegeLord]

I didn't know 16 bit PNGs even existed, I'm not surprised this hasn't come up before.

Regardless of what's done, we should at least gracefully reject formats we can't handle.

[pedro-w]

...I think maybe TIFF also supports higher bits per channel.

How about retaining the current code (should be fast) but falling back to the drawing context option if the current code can't handle it? At the moment AFAICS there's no else clause to catch unhandled format so we don't write anything into the target bitmap!

I can investigate if no-one else feels motivated to.

[allefant]

As a workaround - you can disable the native image addon and fall back to libpng (I don't remember if because of this specific bug, but the native addon never worked for my pngs - I just never investigated more).

[pedro-w]

I've looked into the render to context option, it works on the png file here and on an 8-bit png. All bitmap loads (bmp, jpg, ...) on MacOS will pass through that function so it's a bit scary to be changing it. I will post some code soon so others can weigh in.

I've also started on trying CIImage , currently it is messing up the colours (swapping channels I guess) and I'm not sure why. (CoreImage looks pretty heavy but the only parts we need are "image from data" and "render to bitmap")

More later!

[pedro-w]

Have pushed some code, please have a look
https://github.com/pedro-w/allegro5/tree/issue-1531
(definitely not ready for a PR yet - in particular I'm not really sure I understand premultiplying alpha)
I think it's better than what was there before - we're still at the mercy of MacOS built-in image handling but via CoreImage rather than AppKit (both of these end up in CoreGraphics I suppose)
It would be great if someone could have a play with some usual and unusual bitmap formats.

[pedro-w]

Ironically I was hit by this myself yesterday - spent ages trying to debug something when the issue was that ImageMagick's montage command had created a 16 bit-per-channel PNG for me 😠

[lockie]

@pedro-w Hey, I've tried your fork under MacOS virtual machine and I'm afraid it still outputs the 16-bit PNG image from OP incorrectly:

(and just a small observation, the visual garbage itself is different every time I launch ex_bitmap_file)

[pedro-w]

Disappointing. It worked for me. What version of MacOS are you using?
The visual garbage would be different every time under the old code because it allocates the memory and then sees a format it can't handle and skips the writing stage. The result is a bitmap made of of uninitialized memory.
Pete

[lockie]

That'd be Monterey.
Let me know if I can add some debugging code to clear this thing up.

[pedro-w]

One useful thing would be to just fwrite the contents of the surf array, round about line 52.
Then you can use ImageMagick to convert it to a normal image file. Then we'll see if the problem is (stage 1) loading the image data with CoreImage or (stage 2) the conversion to an Allegro bitmap.

[lockie]

Oh, so sorry, I forgot to checkout the correct branch 😅
With your changes actually applied the image in question is indeed displayed correctly.