lovasoa / dezoomify-rs

Zoomable image downloader for Google Arts & Culture, Zoomify, IIIF, and others
https://dezoomify-rs.ophir.dev
GNU General Public License v3.0
742 stars 66 forks source link

Dezoomify-rs Color Distortion #259

Closed IGUPAYITI closed 2 months ago

IGUPAYITI commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Try hue-tint correction/normalisation.

lovasoa commented 2 months ago

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.

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 commented 2 months ago

I reported the issue upstream here: https://github.com/image-rs/image/issues/2333

lovasoa commented 2 months ago

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