Image colors washed out after saving with MaskEditor | Image Canvas

[MetaZuo]

Prerequisites

• I am running the latest version of ComfyUI
• I have searched existing issues to make sure this isn't a duplicate
• I have tested with all custom nodes disabled (see how)

What happened?

A single saving in MaskEditor | Image Canvas causes the image colors to be washed out / desaturated. No other operation (like painting) is needed to reproduce. This bug seriously damages inpainting.
Not related to browser, go into ComfyUI/input/clipspace and you notice the color difference in Windows photo viewer. This single saving creates 4 files:

clipspace-paint-1766934508449.png
clipspace-mask-1766934508449.png
clipspace-painted-1766934508449.png
clipspace-painted-masked-1766934508449.png

the first one is a completely black image, the second one has correct colors, and other two have washed out colors. Unfortunately the node seems to use the fourth one.

Happens with either Nodes 2.0 on or off. Latest fresh ComfyUI windows portable release (0.6.0) without custom nodes; latest frontend release (1.36.12).

Example
before (example.png in ComfyUI/input):

after

Steps to Reproduce

1. Create a Load Image node and load any image, e.g. example.png in the input folder.
2. Right click on the image and "Open Image", for later comparison.
3. Right click on the image and "Open in MaskEditor | Image Canvas".
4. Click "Save".
5. Right click on the saved image and "Open Image".
6. Compare the colors.

How is this affecting you?

Feature doesn't work as expected

ComfyUI Frontend Version

1.36.12

Browser

Firefox

Console Errors

Logs

Additional Context

No response

┆Issue is synchronized with this Notion page by Unito

[coderabbitai]

🔗 Similar Issues

Related Issues

• Load Image node when you edit it with the mask editor no longer saves the image WITH metadata on ComfyUI\input\clipspace #5881

🔗 Related PRs

#7178 - fix: vue nodes image preview widget, better multi image gallery support [merged]
#7394 - fix: work around Chrome GPU bug causing severe lag when dragging links [merged]

👤 Suggested Assignees

• diodiogod
• simula-r
• jtydhr88

---

Enable issue planning

_{To enable issue planning, add the following to your .coderabbit.yaml:}

issue_enrichment:
  planning:
    enabled: true

_{You can then request a plan by commenting @coderabbitai plan on any issue.}

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dosubot]

Hi @MetaZuo! I'm Dosu and I’m helping the ComfyUI_frontend team.

This is a known issue with the current MaskEditor save logic. The washed-out or desaturated colors in the saved painted-masked image are caused by how the alpha channel is set when compositing the output: the code inverts the mask's alpha (using 255 minus the mask alpha) and applies it to the final image, which can visually wash out colors if the alpha is not handled as expected by image viewers. The RGB channels themselves are not altered, but the browser's canvas and PNG encoding do not manage color profiles or sRGB intent, so color shifts can occur—especially when viewing the result in apps like Windows Photo Viewer that may not interpret transparency or color space the same way as browsers do. There is no explicit color management or workaround in the frontend code right now, and similar mask/paint layer issues have been reported since the new mask editor was introduced, even with custom nodes disabled. The maintainers are aware of persistent mask editor and preview breakages after recent frontend refactors, but this specific color desaturation issue is not directly tracked in open tickets yet. For now, the only workarounds are to use the old mask editor (if still available) or post-process the output externally if color fidelity is critical.
Source: MaskEditor save logic and related issues
Related user reports
Discussion of mask editor/preview breakages

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[MetaZuo]

@dosu
I did several more tests, with and without mask, and it seemed to not happen every time, but at a pretty high chance.
This is affecting inpainting by making colors degrade through passes, since the image data provided to downstream nodes is off, and the final output saved by user is visually damaged.
I don't think the key problem is the alpha channel. Guess the code related to creating the "-painted-" files is to blame. Because the "clipspace-mask-.png" files are always good, which come with only the mask information (in alpha). Things seem to go wrong when any user-made painting edit is applied (even it is empty as in my example). The node passes the painted version downstream, as it should do, and that causes the problem.

[dosubot]

The color degradation in the "-painted-" files is caused by how the MaskEditor save logic composites the original image and the paint layer, then applies the mask's alpha channel (inverted: 255 minus mask alpha) to the final image before saving as PNG. This process involves repeated RGBA buffer conversions and relies on browser canvas defaults, which do not preserve color profiles or sRGB intent. As a result, even empty or minimal paint edits can trigger the issue, and the output may appear washed out or desaturated—especially in external viewers that interpret PNG alpha differently. The mask-only files are unaffected because they skip the paint layer compositing step and only apply the mask alpha to the original image. This issue is not directly tracked in open tickets, but similar paint layer problems have been reported since the new mask editor was introduced, even with custom nodes disabled. For now, you can try post-processing the output or using alternative viewers if color fidelity is critical.
Source: MaskEditor save logic
Related user reports

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[MetaZuo]

New findings:
This bug have been there for at least two months. It was already there in ComfyUI portable v0.3.68 which means frontend v1.28.8. It wasn't there in ComfyUI v0.3.8 which was possibly the first version with the new MaskEditor, so it was imported some point in the between. I didn't have time to do a binary search for the accurate version number.

The reason why I didn't realize it before is that I had been using the Preview Bridge node from ComfyUI-Impact-Pack to do mask editing. And Preview Bridge does something that is supposed to be a bug: after you finish editing in MaskEditor (but don't run an execution), the node displays the "clipspace-painted-masked-[id].png" file, which is consistent with Load Image node;

(notice the green color in the middle Preview Bridge node)

but the time you run an execution, Preview Bridge suddenly switches to the "clipspace-mask-[id].png" file - the one with correct colors. You can verify it by opening the image in browser and checking the filename. So downstream nodes (like Preview Image, and all kinds of nodes for inpainting) receives the image with correct colors.

(correct colors in the middle)

This should be a bug of the Preview Bridge node because you just lose your paint edit. But I had been using only the mask edit for inpainting. So this bug unintentionally "fixed" the color problem for me in my inpainting workflows.

However recent frontend updates broke Preview Bridge (#7665) so I had to use the Load Image node instead, and found the long existing color problem.

May I mention @ltdrdata in case they have some insight?