Closed IGUPAYITI closed 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.
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
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.
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
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.
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?
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.
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.
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.
Try hue-tint correction/normalisation.
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.
overall | red | green | 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.
I reported the issue upstream here: https://github.com/image-rs/image/issues/2333
v2.13 downgrades image-rs to v0.24 and should fix the issue
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: