Incorrect Pixel Decoding in Brave on Linux (p5.js `img.pixels[]` vs `get()`)

[akashdeepnandi]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• p5.strands
• WebGL
• DevOps, Build process, Unit testing
• Internationalization (i18n)
• Friendly Errors
• Other (specify if possible)

p5.js version

1.11.8

Web browser and version

Brave Browser 138.1.80.122

Operating system

Pop!_OS 22.04 LTS

Steps to reproduce this

🧩 Summary

Hello everyone, I was trying to follow along with the Coding Challenge Wave Function Collapse Overlapping Model from Coding Train - https://youtu.be/5iSAvzU2WYY?si=5sAHz7IPha8vNkzn. While trying to create the calculateNeigbors function I suddenly saw a bug which took several hours but now I have discovered the bug behaviour.

When using p5.js to access image pixel data with .pixels[], the returned values in Brave Browser on Linux are incorrect at random r,g,b values. Example:

• img.get(0,0) returns [255, 255, 255, 255] (as expected)
• img.pixels.slice(0, 4) returns [254, 255, 255, 255] (unexpected)

The same code, on the same system, returns the correct [255, 255, 255, 255] in Google Chrome.

---

✅ Steps to Reproduce

p5 Sketch Link: - https://editor.p5js.org/mrvoid/sketches/qxk1DTOjZ

1. Use the following p5.js sketch:

let img;

function preload() {
  img = loadImage("city.png"); // attach this PNG in the report
}

function setup() {
  noCanvas();
  img.loadPixels();

  console.log("img.get(0,0):", ...img.get(0, 0));
  console.log(
    "img.pixels[0-3]:",
    img.pixels[0],
    img.pixels[1],
    img.pixels[2],
    img.pixels[3]
  );
}

2. Open it in Brave browser on Linux

3. Observe console output:

   img.get(0,0): 255 255 255 255
   img.pixels[0-3]: 254 255 255 255
   

4. Repeat in Google Chrome → output is correct (255 255 255 255 for both)

5. Also if you observe, full pixel array you will see many discrepencies.

---

📸 Screenshot / Output

(img.get)    → [255, 255, 255, 255]
(img.pixels) → [254, 255, 255, 255]

Brave

Chrome

---

💻 System Information

Date Collected: 2025-08-04

🔧 System Info

$ uname -a
Linux pop-os 6.12.10-76061203-generic #202412060638~1751390742~22.04~79b9668 SMP PREEMPT_DYNAMIC Tue J x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

---

🧠 CPU Info

$ lscpu
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
CPU(s):                               16
On-line CPU(s) list:                  0-15
Model name:                           AMD Ryzen 7 6800H with Radeon Graphics
NUMA node0 CPU(s):                    0-15

---

🎮 GPU Info

$ lspci | grep -i vga
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 73ef (rev c3)
08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt (rev c8)

---

📺 OpenGL/Graphics Info

$ glxinfo | grep -E 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon Graphics (radeonsi, rembrandt, LLVM 15.0.7, DRM 3.59, 6.12.10-76061203-generic)
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.2.8-1~bpo12+1pop1~1744225826~22.04~b077665

---

🌐 Browser Versions

$ brave-browser --version
Brave Browser 138.1.80.122

$ google-chrome-stable --version
Google Chrome 138.0.7204.157

---

🔍 Additional Details

• p5.js version: 1.11.8
• Sketch Link - https://editor.p5js.org/mrvoid/sketches/qxk1DTOjZ
• PNG image: 9×9 with red, blue, and white pixels (white is at (0,0))
• Behavior observed with and without WebGL mode

---

🛠 Potential Cause (Hypothesis)

• PNG decoding in Brave may apply slightly different gamma correction or color rounding when populating canvas pixel data.

$ identify -verbose city.png | grep Gamma
  Gamma: 0.45455
    png:gAMA: gamma=0.45455 (See Gamma, above)

---

📎 Attachments

• city.png
• Console screenshot (Brave vs Chrome)
• This Markdown report

---

NOTE: You can let me know if I need to open the bug with Brave or Chromium team. I opened it up here as I wanted to notify the people who are trying to learn do not get stuck at this.

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms.

For guidance on contributing, check out our contributing guidelines and other resources for contributors.
💬 If you have questions or need support, feel free to join the Processing Foundation Forum or visit our Community page.
📜 Please also review our Code of Conduct to understand our community standards.
Thank You!

[RandomGamingDev]

Hello, I'm a steward for WebGL.

When using p5.js to access image pixel data with .pixels[], the returned values in Brave Browser on Linux are incorrect at random r,g,b values.
Example:

• img.get(0,0) returns [255, 255, 255, 255] (as expected)
• img.pixels.slice(0, 4) returns [254, 255, 255, 255] (unexpected)
  The same code, on the same system, returns the correct [255, 255, 255, 255] in Google Chrome.

I would love to assist, but I was not able to replicate the issue on the Firefox, Chromium, or Brave. It's quite possible that it could be something that's wrong with a specific version of their browser so it's best to test with the latest version in order to make sure of that before making unnecessary changes to p5.js itself.

I'm not on the exact same versions as you (I'm running Debian with a discrete GPU), but I am also running it on Linux on Brave. However, running it on the latest version (v1.81.131) didn't give the same result.

Would you be able to test on the latest version of Brave as well?