Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] - image appearance changed without my input or approval #612

Open
Abby-Williams opened this issue Dec 20, 2024 · 3 comments
Open

[BUG] - image appearance changed without my input or approval #612

Abby-Williams opened this issue Dec 20, 2024 · 3 comments

Comments

@Abby-Williams
Copy link

Version: 9.0 (portable)

Describe the bug

Opening certain images makes them go pale and desaturated. And when they're saved they permanently turn that way. I didn't notice at first and spent an hour pixel editing it (becauuse I focused on other parts that were less affected), now I don't know how to make it go back to the original.
98ba3362ab
febbf2a80a

How can I reproduce the bug?

Open the first linked image in photodemon 9.0, it immediately starts looking like the second. (That image is only a crop of the original I was working on, but the same bug still happens to it.)

Expected behavior

That the program does not mutate the colour scheme without even asking me

Debug logs

I opened the file again then crashed photodemon with taskmanager, if that's the bug report you mean
DebugReport_0.zip

Thank you!

As a "thank you" for your help, I am happy to add your name to PhotoDemon's contributor list. Please let me know what name (and optional website link) you'd like me to use.

Abby_Williams

@tannerhelland
Copy link
Owner

Hi @Abby-Williams . Thank you for reporting this issue. I'm sorry that PhotoDemon didn't behave how you expected!

To restore the "expected" colors, go to the Adjustments > Lighting > Gamma menu, and use the value 0.56 in all color boxes. This will make the colors look like the second image you attached.

The first PNG image you attached provides incorrect chromaticity values. Whatever website or program you used to obtain the image is the source of the bug, and they will need to fix it. (From the file, it looks like this was ezgif.com?) Chromaticity values are stored in the PNG file in the cHRM chunk, described on this page of the PNG specification in the section titled "4.2.2. cHRM Primary chromaticities and white point":

https://www.w3.org/TR/PNG-Chunks.html

PhotoDemon follows the spec precisely, including the decoder recommendation where it says...

Decoders running on platforms that have a Color Management System (CMS) can pass the image data, gAMA and cHRM values to the CMS for display or further processing.

PhotoDemon does precisely this, and the chromaticity data in the PNG file produces the first image you see above.

The app or website you used needs to either stop writing chromaticity values to their PNGs, or they need to write gamma correction to the file as well which would also fix the problem. (1 / 1.8 is the gamma value they should write, which is why the Adjustments > Lighting > Gamma correction with a 1 / 1.8 value - or 0.56 - restores the colors you expected).

Some photo editing apps simply ignore any stored chromaticity values in PNG values, which breaks correct PNG files but can provide a workaround for buggy ones. I may need to add a toggle to PhotoDemon to allow this behavior as well, but that's a sizeable project and I won't be able to do it until after the holidays. I also get frustrated writing workarounds for other apps that are broken, but I understand that as a user, you just want things to "look right"!

In the meantime, either use a different tool to create your initial PNG files, or use the gamma correction adjustment I described to "fix" the broken color data.

I hope this information helps. I'll report back if I'm able to add a toggle to PhotoDemon to turn off color management in PNG files.

@Abby-Williams
Copy link
Author

Abby-Williams commented Dec 25, 2024

Thank you for replying! I did indeed use ezgif for cropping the image, before editing in Photodemon.
Testing with a dozen random PNGs I had (even black-and-white ones), cropping or otherwise editing them in ezgif, made all of them look pale and washed out in PhotoDemon. But it didn't affect their appearance in other programs I tested (Paint, Paint3D, default windows Photos app and Snipping Tool, GIMP, qView, XnView, XnView Classic, Faststone, Irfan Viewer). cHRM doesn't seem to be getting the attention somehow
Removing the cHRM chunk did make the original image also look normal in Photodemon, but not the pale image. Neither did the gamma adjustment to 0.56 you advised; it somehow turned the pale image darker than the original was. And it seemed that there was no gamma adjustment that made it go back exactly to how it was. The result always was redder somehow. Flicking through the two images in qview, the transition between them was visible. Something else happened to the image, but I hadn't done any global corrections to it.

argsdthfnhm

tannerhelland added a commit that referenced this issue Dec 28, 2024
Relates to #612 .

There is now a `Tools > Options > Color Management` option that says "use format-specific color management data, when available".  I've now implemented this toggle for PNG images.

PNGs provide a variety of color-management settings *separate* from traditional ICC profiles  This toggle can now be used to turn OFF correction based on e.g. embedded gamma (gAMA) and chromaticity (cHRM) data.  This breaks the PNG spec and causes PD to produce different images from all major web browsers, but it also provides a way to rescue images with faulty gamma or chromaticity chunks (as produced by e.g. ezgif.com, which prompted this change in the first place).

Thank you to @Abby-Williams for catching and reporting this issue.
@tannerhelland
Copy link
Owner

Thank you so much for the follow-up, @Abby-Williams. I really appreciate you sticking with this problem!

I've just uploaded a new PhotoDemon nightly build with some new features to help us fix this. You can download the new build manually, or set the Tools > Options > Updates preference to stable, beta, and developer releases. Then manually check for updates and let PhotoDemon apply the update for you.

If I understand correctly, we have two problems to solve:

  1. Making GIFs from ezgif.com load with "correct" colors in PhotoDemon
  2. Rescuing an ezgif.com image you edited in PhotoDemon, that started out with "broken" colors and now is stuck with those colors (but you don't want to lose your edits).

Problem 1 can be solved using a new preference in the Tools > Options > Color Management panel. Turn OFF the preference that says use format-specific color management data, when available to make PhotoDemon ignore any embedded chromaticity data in PNG files:

image

Once that setting is turned off, PhotoDemon will operate like the other photo editors, and simply ignore chromaticity corrections in PNG files. (Try loading some ezgif.com images and they should look "OK".)

Now for problem 2.

When a PNG file has chromaticity data embedded in it (that's what a cHRM chunk holds), PhotoDemon applies that data to the image at load-time. This data potentially affects all color channels and luminance in the image. Using this data allows PhotoDemon to display images exactly like web browsers do, like with the images in this test page:

http://www.libpng.org/pub/png/png-colortest.html

(The top row of images, for example, display correctly in PhotoDemon, but not in any of the photo editors you mentioned.)

I apologize for wrongly assuming that a gamma correction would help. (It's hard to know what to suggest when only working with a fraction of the source image!) I should have tested more carefully instead of guessing 🫤

I'm going to study PhotoDemon's chromaticity adjustments to nail down precisely what's going wrong (this will take some time), but in the meantime, let's figure out a way to fix the colors in your edited image.

PhotoDemon has a tool that lets you build a custom color correction from a "before" and "after" image. We're going to use that to create a filter that "undoes" the chromaticity adjustment on this particular image. Because I don't have the full images, I need you to do this on your end, then report back. Here are the steps required.

  1. Turn ON the new use format-specific color management data, when available setting in the Tools > Options > Color management panel.
  2. Load the original problem image from this thread. It should appear too bright.
  3. While keeping that image open, turn OFF the new use format-specific color management data, when available setting in the Tools > Options > Color management panel.
  4. Load the original problem image from this thread again. You should now have two copies open: one that looks right, and one that looks wrong.
  5. Switch to the image that looks CORRECT. Use Edit > Copy to copy the correct image to the clipboard.
  6. Switch to the image that looks WRONG. Use Edit > Paste to paste the correct image over the top of it.
  7. Use the Image > Flatten image... menu to smash the two layers together.
  8. Finally, use the File > Export > Color lookup... menu. Use the CUBE format and any filename you want. The default export settings should work okay. (You can try the "extreme" setting for maximum quality, but it will be a little slower and the file will be larger.)
  9. You now have a custom filter file that effectively converts colors from the wrong chromaticity to the correct chromaticity.
  10. Load the image you edited, then use the Adjustments > Color > Color lookup... tool, and select the CUBE file you just made from the list. Apply it, and this should fix the colors to the way you want them to be.

I'm sorry that list of steps is so long. (I also hope it works!)

Thank you in advance for any follow-up information you can provide. I'm eager to get this resolved for you.

tannerhelland added a commit that referenced this issue Dec 30, 2024
This fixes images coming from ezgif.com, and appears to mirror current behavior in most color-managed web browsers.

I can't promise it won't break other (already broken) images but since we have to guess at a relevant gamma value, we may as well go with the PNG default.  (Note, however, that 2.2 is an ancient default from CRT monitor days - see http://www.libpng.org/pub/png/spec/1.2/PNG-Decoders.html#D.Decoder-gamma-handling)

Relates to #612
tannerhelland added a commit that referenced this issue Dec 30, 2024
Got a lot more formats to cover, but this is at least a start!

(I'm also temporarily disabling the fix in 7741be7 pending feedback in #612 ; I'll re-enable once I know that situation is resolved.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants