RGB image created with “createImage()" has alpha channel.

[processing-bot]

Created by: ertdfgcvb

Description

Images created with createImage(w, h, RGB) have an alpha channel.
The alpha channel is filled with 0 once a single pixel is set.

Expected Behavior

RGB images should be opaque (?).

Current Behavior

A newly created RGB image has all pixels in black but once a single pixel is changed trough the set() method the alpha channel is zeroed out (?) for all other pixels.

Steps to Reproduce

PImage a = createImage(10, 10, RGB);
// Uncomment below for a different result!
//image(a, 5, 5); 
a.set(0, 0, color(255,0,0));
image(a, 20, 5);

Your Environment

• Processing version: 4.0b3
• Operating System and OS version: MacOS 10.15.7

[processing-bot]

Created by: benfry

Hm, the alpha should be ignored. When I first tried your example I saw the weird behavior—nothing was drawn, and then using set() showed two mostly black rectangles.

Though given that I can't reproduce it, I wonder if it's just a matter of nothing being drawn at all—i.e. the set() call does enough to flush the graphics buffer, but we're dealing with an unrelated glitch.

For what it's worth, in RGB images, the high 8 bits of the pixels should simply be ignored—they might be 0x00 or might be 0xFF depending on how they've been set (i.e. createImage() will leave them at 0x00, but set() will probably make the pixel 0xFF), but their having different values is a red herring as far as debugging goes.

[processing-bot]

Created by: benfry

I would also try with beta 4…

[processing-bot]

Created by: ertdfgcvb

Tested on beta 4 (macOS) with the same outcome.

PImage a = createImage(10, 10, RGB);

// Uncomment below to set a few red pixels:
// after a single set() call the alpha turns 0x00
// a.set(0, 0, color(255,0,0));
// a.set(1, 0, color(255,0,0));
// a.set(2, 0, color(255,0,0));

image(a, 5, 5);

Before set():

After set():

[processing-bot]

Created by: benfry

Thanks, that's a helpful test case.

[processing-bot]

Created by: benfry

Fixed for beta 6.

This is a nasty one because it's partly a performance tradeoff—we could manually set all the pixels to be opaque, but that's a really expensive operation, and in most use cases, the pixels will already be opaque. But we have a better solution for it now.

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.