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

Dezoomify-rs Color Distortion #259

Closed
IGUPAYITI opened this issue Sep 10, 2024 · 13 comments
Closed

Dezoomify-rs Color Distortion #259

IGUPAYITI opened this issue Sep 10, 2024 · 13 comments

Comments

@IGUPAYITI
Copy link

Hello, when downloading through dezoomify-rs images have a very noticeable green shade if saved as jpg and a mild one if saved as png/tif, regardless of compression. There is no problem if the image is downloaded with the browser but it is very slow and with the site I can't download very large image at full resolution. If you can download the images and view them, switching from one to one, it is very noticeable (I'm using Photoshop), particularly between jpg-rs and png-web (you need to pay attention to see it between png-rs and png-web but it is there).
How can I solve this problem? Thank you.
Images for reference:

  1. jpg da dezoomify-rs

1

  1. png da dezoomify-rs

2

  1. png da dezoomify-web

3

@IGUPAYITI
Copy link
Author

I have checked and you can see the difference that I'm talking about in browser by open all images link and switching through them. Very noticeable with the first image, to see it between 2 and 3 focus on the lady's hair and you will see the green shade.

@Cosmicore
Copy link

Cosmicore commented Sep 13, 2024

How to compare them if they are different in size/color?

JPEG 4576×6000, 24 bits
PNG 3203×4200, 8 bits (both files)

What's in the original? Either one image (jpg) is expanded to a higher resolution and color (adding what is not in the original; we are not discussing the losses/artifacts caused by jpeg compression itself, but they are also present), or another image (png) is reduced to a lower resolution and color (losing what is in the original).

Ok, let's assume that the resolution was lowered when the png files were uploaded to Github. Look at the parameters of the images in your PC copy, whether they have different numbers of colors or not (8, 24, 32 bits). I believe the original image is 4576×6000, 24 bits.

Try this command for jpeg: dezoomify-rs.exe URL -l --compression 0

@IGUPAYITI
Copy link
Author

Hi,
The corruption is always a green shade, not just in this particular file, so I think it is regardless of the color in the original image. I've also already tried to download with zero compression with no changes, both png and jpg. Downloading as TIFF (no compression by default) with -rs bear the same results as downloading as png. The files were originally of the same sizes (as you said 4576×6000, the largest download available) but the png were too big for github so I reduced pixels and compressed bits with Photoshop (the 2 png have gone under the same procedure and the green shade is visible in the attached files, plus the non reduced jpg is clearly the worst one). I assure the problem is visually identical in the original and in every files I've downloaded with -rs. I was ingenuous to upload different size files, the images were just for references. It's interesting that I have no problem through the website apart downloading very large files.
Cosmicore, thank you for trying to help by the way.
For now I think I will use the browser extension even though it's very slow compared to -rs and wait the next exe version, maybe it will fix this.
My only problem now are very high resolution paintings. Can someone suggest a workaround for Chrome? I use chrome because Firefox doesn't work for me, "save as..." doesn't do anything and opening an image in a new tab wash out the colors, again I don't know why, I think it's a Firefox issue.
Thank you all, especially to lavasoa, for the still amazing work.
Have a nice day.

@Cosmicore
Copy link

Cosmicore commented Sep 13, 2024

Got it! Try dezoomify-rs.exe version 2.12.1 (not newer).

Version 2.12.1 (and older) works differently (at least I can see that the colors are different from what I get in newer versions).

Version 2.12.2 gives an error “ERROR Input/Output error: The encoder or decoder for Jpeg does not support the color type Rgba8”.

Version 2.12.3 gives me “your” greenish “distorted” colors. The developer (@lovasoa) seems to have solved the bug in the previous version. Maybe this is the reason for what is happening with colors? I really don't know.

Version 2.12.4 doesn't seem to work on my current PC with Windows 7, so I can't test it right now (need the bcryptprimitives.dll library and other related libraries).

P.S. You'll find all the versions of dezoomify-rs here
https://github.com/lovasoa/dezoomify-rs/releases

@lovasoa
Copy link
Owner

lovasoa commented Sep 13, 2024

Oh, it looks like you are reporting a regression ! I'll have to look into this.

But I don't see the difference between the three images above to the naked eye.

@Cosmicore
Copy link

It was almost impossible for me to see the difference, too. This greenness is so elusive and seems natural!

In order not to depend on different formats and sizes, I did not use the pictures provided by @IGUPAYITI, but downloaded them myself with different versions of dezoomify-rs, and then opened both. When switching from one to the other image, I immediately saw that subtle difference and that greenish.

Here, look at the light colors on the chest, can you see the slight difference?

2 12 1_2 12

@IGUPAYITI
Copy link
Author

IGUPAYITI commented Sep 13, 2024

Wow @Cosmicore, amazing work!
Yeah, it's is very elusive. I spotted it only when preparing some images for print using multiple copies of the same painting downloaded differently. It was already some weeks that I was using -rs latest version and never realized it.

@Cosmicore
Copy link

I just noticed that @lovasoa promptly released the new version 2.12.5 yesterday. Thanks a lot, @lovasoa !

@IGUPAYITI, have you tested it yet? I'm very interested in what you would say, is your problem (issue) solved?

I'm on a Windows 7/64 machine again now, and here the new version doesn't start at all, it immediately crashes with the error “The application was unable to start correctly (0xc0000005)”. So I can't test it right now and report the results.

@IGUPAYITI
Copy link
Author

Hello, I tested it now, the "green" was still there!
I also compared 2.12.5 with 2.12.1 and can confirm what @Cosmicore said, it seems that this version works fine.
Sorry I can't be of more help, I don't know anything about programming.

@DigitalCurator
Copy link

Try hue-tint correction/normalisation.

@lovasoa
Copy link
Owner

lovasoa commented Sep 25, 2024

I ran an experiment.

Downloaded an image to jpeg with the least possible compression, while saving the original tiles from the web server

dezoomify --max-width 2000 --tile-cache /tmp/  --compression 1 https://artsandculture.google.com/asset/etude-pour-vers-le-bleu/1gH8RLY-nW279Q dezoomified.jpg

Re-cropped the result to get the top left tile

convert dezoomified.jpg -crop 512x512+0+0 /tmp/result-cropped.png

Compared the dezoomify result with the original tile from the server:

$ magick compare -verbose -metric mae /tmp/https_lh3.googleusercontent.com_ci_AL18g_SoY-4khVkxbU1swZDjGJZ7B-Pr7Xi4tNu8lKfubds6Pfkvju_nZZUEkmPyT_YullP3QHc\=x0-y0-z2-trEswzuVEAlEsEgi3t1mkU9p3hZE /tmp/result-cropped.png /tmp/difference.png
/tmp/https_lh3.googleusercontent.com_ci_AL18g_SoY-4khVkxbU1swZDjGJZ7B-Pr7Xi4tNu8lKfubds6Pfkvju_nZZUEkmPyT_YullP3QHc=x0-y0-z2-trEswzuVEAlEsEgi3t1mkU9p3hZE JPEG 512x512 512x512+0+0 8-bit sRGB 25514B 0.000u 0:00.006
/tmp/result-cropped.png PNG 512x512 1701x1192+0+0 8-bit TrueColor sRGB 139508B 0.010u 0:00.005
Image: /tmp/https_lh3.googleusercontent.com_ci_AL18g_SoY-4khVkxbU1swZDjGJZ7B-Pr7Xi4tNu8lKfubds6Pfkvju_nZZUEkmPyT_YullP3QHc=x0-y0-z2-trEswzuVEAlEsEgi3t1mkU9p3hZE
  Channel distortion: MAE
    red: 652.666 (0.00995904)
    green: 182.666 (0.0027873)
    blue: 792.326 (0.0120901)
    all: 542.553 (0.00827882)
writing raw profile: type=icc, length=868
/tmp/https_lh3.googleusercontent.com_ci_AL18g_SoY-4khVkxbU1swZDjGJZ7B-Pr7Xi4tNu8lKfubds6Pfkvju_nZZUEkmPyT_YullP3QHc=x0-y0-z2-trEswzuVEAlEsEgi3t1mkU9p3hZE=>/tmp/difference.png JPEG 512x512 8-bit sRGB 25514B 0.060u 0:00.050
compare: profile 'icc': 0h: PCS illuminant is not D50 `/tmp/difference.png' @ warning/png.c/MagickPNGWarningHandler/1526.
  • The MAE represents the average absolute difference in pixel values between the two images.
  • The normalized values (in parentheses) are obtained by dividing the MAE by the maximum possible error (255 for 8-bit images).
  • A normalized MAE close to 0 indicates high similarity, while values closer to 1 indicate significant differences.

result-cropped

result-cropped

original server tile

original-server-tile

difference

overall red green blue
difference difference-red difference-green difference-blue

The red areas of the difference image emphasizes (highlight) pixels that are affected by the process whereas white de-emphasizes (lowlight) pixels that are untouched by the process.

@lovasoa
Copy link
Owner

lovasoa commented Sep 25, 2024

I reported the issue upstream here: image-rs/image#2333

@lovasoa lovasoa unpinned this issue Sep 25, 2024
@lovasoa
Copy link
Owner

lovasoa commented Sep 25, 2024

v2.13 downgrades image-rs to v0.24 and should fix the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants