Glitch: Color Values can change when saving and reloading

[UserRedacted]

Color values change when saving

Steps to reproduce the bug

1. go to piskelapp.com
2. create a new sprite
3. select any brush
4. Paint or draw on the canvas in a way that the colors change frequently from pixel to pixel (at minimum use 2 colors)
5. Save the piskel to the online gallery, then exit
6. Re-open the piskel, and the color pallete will multiply to contain colors you never used

Environment details

• operating system: Windows 10
• browser (or offline application version): Google Chrome

Sprite details

• number of frames: 1
• sprite resolution: 32 x 32
• session duration: 60 seconds

Example: Below, I drew in only complete black (#000000) and red (#FF0000), but when I exit and reload, the singular black turns into various shades of black.

[UserRedacted]

 I absolutely love this program, but this glitch has made it almost impossible for me to make and edit textures. I've been trying to use a limited palette of pure white, pure black, and a gray that is exactly in the middle. When editing a sprite, it is extremely important for me to be able to easily select, highlight, or replace all of one color. With this glitch, editing sprites goes from simply pressing a few buttons, to spending up to hours manually replacing glitched pixels.

 Because this bug seems affect every export option, also have no way of addressing it. Every time I save the program, some of the colors are inevitably corrupted and my editing process suffers greatly from it. This has really been bothering me, because no other pixel program compares to Piskel in terms of UI, UX, and features. I hope this can be fixed, because if not, I genuinely think I won't be able to use this program to do what I'm trying to do.

[juliandescottes]

Hi,

Piskel relies on the browser to preserve colors when using a few APIs around canvas. I guess that what happens here is that when Chrome is asked to turn the canvas into a PNG image (which is how it gets saved), for some reason it will perform a lossy compression. This is probably hardware dependent. I guess that Chrome delegates this kind of instruction to the graphics card if hardware acceleration is turned on for instance.

The alternative would be to re-implement a save that manually creates a proper PNG (or any other lossless image format). It's bound to be a lot slower, but I guess it can be done and proposed as a setting for users experiencing color corruption such as this.

In the meantime could you:

• share which hardware you have, if you know (is it laptop or desktop, dedicated graphics card etc...)
• go to chrome://gpu/ and copy the report here
• maybe try Firefox to see if you experience similar issues

Also can you confirm this only occurs when saving and not before?

[juliandescottes]

It's possible that we could reuse ArrayBufferSerializers now. When it was initially implemented in 2016, the browser support for those APIs was a bit poor. But now it seems to be better across the board. I wonder if this would solve the issue. I will try to put a modified version of the editor online which can save using arraybuffer.

Basically need to undo 2a7957b

[UserRedacted]

Interesting!
So for Google Chrome, I have hardware acceleration turned off, so theoretically my GPU (RTX 3070) shouldn't be interfering.
I'm running on a custom-made desktop. Regardless, I will copy the chrome://gpu/ report to its own comment below.

On my desktop, the error did not appear to be present on Firefox or Edge, which is great! I know you don't support Opera, but I wanted to confirm that it wasn't a Chromium error, so I tested it on Opera as well. As far as I can tell, this is exclusively a Google Chrome glitch. I can't replicate it on any other browser. I made a demo file in Firefox, edited it in Edge, and loaded it repeatedly between the two, and did not have the color glitch show up. However, the moment that I loaded the uncorrupted file into Chrome, the color glitch appeared again. Alternatively, when I work on the project in Chrome, save it in Chrome, then open it up in Firefox or Edge, the color glitch is also present. So it looks like any time the canvas is saved or loaded in Chrome, the glitch is present. I think your theory on lossy compression is probably spot-on.

Also, I have been unable to replicate the glitch without saving as of yet. So the TL;DR is:

1. Error only appears in Chrome
2. Error only appears when saving/loading in Chrome

p.s. - the error was present both with hardware acceleration off and on

[UserRedacted]

Graphics Feature Status

• Canvas: Software only, hardware acceleration unavailable
• Compositing: Software only. Hardware acceleration disabled
• Multiple Raster Threads: Enabled
• Out-of-process Rasterization: Disabled
• OpenGL: Disabled
• Rasterization: Software only. Hardware acceleration disabled
• Skia Renderer: Enabled
• Video Decode: Software only. Hardware acceleration disabled
• Vulkan: Disabled
• WebGL: Software only, hardware acceleration unavailable
• WebGL2: Software only, hardware acceleration unavailable

Problems Detected

• Gpu compositing has been disabled, either via blocklist, about:flags or the command line. The browser will fall back to software compositing and hardware acceleration will be unavailable.
  Disabled Features: gpu_compositing

Version Information

Data exported	2021-07-02T17:31:43.376Z
Chrome version	Chrome/91.0.4472.124
Operating system	Windows NT 10.0.19041
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/7345a6d1bfcaff81162a957e9b7d52649fe2ac38/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/7345a6d1bfcaff81162a957e9b7d52649fe2ac38/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	3d4f87ab5b9b
2D graphics backend	Skia/91 b0b613b2976c90bccfab56f27fd749cf051a5725
Command Line	"C:\Program Files\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=SecurePaymentConfirmation

Log Messages

• [7624:21676:0702/102917.012:ERROR:gpu_init.cc(440)] : Passthrough is not supported, GL is swiftshader
• GpuProcessHost: The info collection GPU process exited normally. Everything is okay.
• GpuProcessHost: The info collection GPU process exited normally. Everything is okay.

[Lumios64]

This is a bug I have just experienced, not by downloading and then re-uploading the sprite, but during editing: the sprite will suddenly become corrupted/compressed into dozens of shades of every color unexpectedly.

It is absolutely infuriating to me - I tried to download the sprite I was working on, opened gimp, converted it to indexed colors then re-uploaded it back to Piskel and it is still affected.

Coincidentally, I use the latest version of Brave which runs on the same engine as Google Chrome.

If this is a problem with the browser and not Piskel per se I would like to enable or disable whatever is causing this, this didn't happen before.

[lightscarecrow3]

This bug kept happening again and again with me on the online, browser version of Piskel. I downloaded the current offline version, chose a color and completely recolored my sprite but it has happened frequently over my last project.

I'm using Firefox and I have no idea what to do.