Image Optimization

[vardaan-raj]

I have simply optimized the images by compressing their size without compromising their quality to make them more space efficient

[grlee77]

Thanks @vardaan-raj.

We should not modify any images under the skimage/data folder. Changes to those will break the SHA256 checksums stored in skimage/data/_registry.py and may cause some test case failures or unexpected changes to downstream user code that relies on the exact pixel values. I think it happened to pass on the Azure CI in this PR because it downloaded previously cached data files (indicating that perhaps we should add additional checks of when to reuse the cache).

The majority of the image size in this project in terms of the website are the images that get generated for the gallery examples at runtime during the documentation builds. We do have image compression (via optipng) running there (see #4800).

[grlee77]

I was surprised this passes tests, but it is because the checks here:

scikit-image/skimage/data/__init__.py

Line 210 in 4b1986e

if _has_hash(resolved_path, expected_hash):

and here:

scikit-image/skimage/data/__init__.py

Line 220 in 4b1986e

if _has_hash(gh_repository_path, expected_hash):

Do not raise an error if the file is found, but the SHA256 does not match. It will instead just move onto the next source, eventually pulling the file from the main branch in this repository. So, none of the tests here are using the modified data files!

[JDWarner]

I agree with @grlee77 for JPEG which is inherently lossy so any re-compression or transcoding will produce artifacts or subtle changes. There are a few .jpg files in here which should be reverted.

However, the majority of these are PNG which is an inherently lossless format which uses lossless compression under the hood (like 7zip or FLAC, not like MP3). For PNGs it is safe to experiment with compression. Though it would require changing the checksums, swapping in a more optimally compressed PNG file yields the exact same data - and this should be simple to verify by loading them in pairs.

For just the PNG files here, could you sum the pre/post size @vardaan-raj to understand the potential space saved? A brief description of the PNG compression technique used would also be appreciated.

[vardaan-raj]

vardaan-raj#1 (comment)

If you can just go to the above link you can see that the image file size has been reduced by 10% and to check for individual size reduction of each image just click on details and you can see a chart showing the initial sizes along with the new compressed sizes.

[vardaan-raj]

The total image size was initially 5,465.43kb and after compression, it came down to 4,908.52kb, a 10.19% reduction

[grlee77]

The total image size was initially 5,465.43kb and after compression, it came down to 4,908.52kb, a 10.19% reduction

In one case a PNG shrank by > 70% and a number of others were > 30% which is not negligable.

@JDWarner's suggestion sounds good to me:
1.) revert the changes to any JPEG files in the data folder
2.) update SHA256 checksums in skimage/data/_registry.py for any PNG files that were modified. This will not need to be done for any of the images under the doc folder, but any modified files that already have a checksum in that registry file will need to be updated.

Let me know if the above is not clear or you need help with either of these suggestions

[vardaan-raj]

Only PNG files have been optimised by img-bot

[vardaan-raj]

How do I update the checksums?

[grlee77]

How do I update the checksums?

On linux I went to the skimage/data folder in a terminal and ran shasum -a 256 *.png. For this branch, I get the following (only a subset of these were changed by imgbot).

f108ee4bbd66a89e2b0d6d5fd81c7e40b6cc74a03b083a890f0135b878413b00  astronaut.png
4d2d021f0a7d8aa16bae8466cf35b1830ae60a3af3d0ab2518e5ca4940c6eb80  block.png
7966caf324f6ba843118d98f7a07746d22f6a343430add0233eca5f6eaaa8fcf  brick.png
c51a0b84a9269594de73f99579720b333bcface4e99519dfd3be44167818791e  bw_text.png
b0793d2adda0fa6ae899c03989482bff9a42d3d5690fc7e3648f2795d730c23a  camera.png
8d23a7fb81f7cc877cd09f330357fc7f595651306e84e17252f6e0a1b3f61515  cell.png
2e207e486545874a2a3e69ba653b28fdef923157be9017559540e65d1bcb8e28  checker_bilevel.png
d7784fad50b59a15b0b1fcff9904a9ce199a60eda0c368de1aae4f969f9e888e  chelsea.png
3e51870774515af4d07d820bd8827364c70839bf9b573c746e485095e893df90  chessboard_GRAY.png
13982eb7c596e16d003ecada8471120975d76572688f46b5b1b5f76780753cbe  chessboard_RGB.png
0f8b39c9829bf019c8168393813a4aa1b99e09b8c693a2e0debb6ae46b8b52ae  clock_motion.png
78769c7b02a40adee579122b73174b60da31474c6134240ec10be806e40d63ed  coffee.png
f44803741520d7f3529f4cf4adff9982c8b900b3ba6b4a6429a8e230bc6fe850  coins.png
7d2df993de2b4fa2a78e04e5df8050f49a9c511aa75e59ab3bd56ac9c98aef7e  color.png
48a64c25c6da000ffdb5fcc34ebafe9ba3b1c9b61d7984ea7ca6dc54f9312dfa  foo3x5x4indexed.png
d6fbd3f7c094262295a651c8b1aa193b6248bba0a3c5347b935c13e16fe8097f  grass.png
056cee2711fb76c49d9efb338bd261f2adc57c45d93a911081b7bdded6dd5515  gravel.png
343f4aaed9658dac0aa6c9c65820643b772c44080c7f4bd799a5552c13273535  green_palette.png
f742f76baff3b84c726d9b921b8c30b64e8c4d4fc4c0d7c8a0458292467bbf6f  horse.png
0c2324ab4adf58710c608a18f3ef8e687a4e2955de44a2e88295c0d099e6fba2  ihc.png
ee790cc1d9c6528f14c307feabb9417f0c39ba3ce815c3c2c65b6cb0c8a6e794  logo.png
d4f8809a453b4470167f98703d5daad37a5b994123b6bc6759e0c48ee253d14b  microaneurysms.png
a5fcc42fc4a34f0f2e5c87fdfdc10a5966f3df1bfefbbba7489d9c4bab13a504  moon.png
8e5b5fcb6cd6b3bf39cfdb93e93bb646c5fc37b08ff24b8de836bb562e3aff16  motorcycle_left.png
b8d1ddd7f55068f199a362965f504eb528136e9f7ad78a490aafdb05d890e8dc  motorcycle_right.png
c702c62db86cf6c0a43e712c844b137f78c4d9c31527b5063cf5bf85d6102e75  page.png
60f1cf3990989782fc26cd4de7f5d91504dd057280464b744be7d618ffd6f7f5  palette_color.png
101f460e14b13715a32e78f339dd2189a47d8fd8805824ffdccd9bd219c1664a  palette_gray.png
7689063ef8453e31a85e056013e76f793d5e31bf5fa29745177456bbbd7c9274  phantom.png
bd84aa3a6e3c9887850d45d606c96b2e59433fbef50338570b63c319e668e6d1  text.png

and for the files in skimage/registration/tests

653de553b1a57f69534978620794ba57aba7f11b0f6dc67f97148e8305441c41  OriginalX-130Y130.png
ed34208397350e87f773cb51335b8940406a9b0b3d3b52757555826dacee53c3  OriginalX130Y130.png
6bf6b88f97fa6d845ab725723e35c1c71f0ded56c5a5a7f4e64b0e70e418a5fe  OriginalX75Y75.png
900df2cbc38da8b2ff044780b836f146d974ab41d4be05c7e5aeff8211191fc6  TransformedX-130Y130.png
5a6766807d6218165d52283dbee584938b22d28f1180af53abc3427f6262abb4  TransformedX130Y130.png
c61bbf89b33dbbae2946191538a81cadc973811ba6544c7324459ac3627c8b91  TransformedX75Y75.png

You would need to change the existing dictionary entries in this variable to match the new values:

scikit-image/skimage/data/_registry.py

Line 43 in 4b1986e

registry = {

If there were hundreds of values to update it would probably be worth writing a custom script to help with this, but it is probably easiest in this case to just paste the values from the terminal into the file individually.

[pep8speaks]

Hello @vardaan-raj! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file skimage/data/_registry.py:

Line 45:42: E231 missing whitespace after ':'
Line 45:80: E501 line too long (109 > 79 characters)
Line 47:41: E231 missing whitespace after ':'
Line 47:80: E501 line too long (108 > 79 characters)
Line 48:42: E231 missing whitespace after ':'
Line 48:80: E501 line too long (109 > 79 characters)
Line 88:80: E501 line too long (93 > 79 characters)
Line 93:80: E501 line too long (98 > 79 characters)
Line 94:80: E501 line too long (91 > 79 characters)
Line 95:80: E501 line too long (96 > 79 characters)
Line 96:80: E501 line too long (90 > 79 characters)
Line 97:80: E501 line too long (89 > 79 characters)
Line 100:80: E501 line too long (89 > 79 characters)
Line 101:80: E501 line too long (89 > 79 characters)
Line 103:80: E501 line too long (87 > 79 characters)
Line 106:80: E501 line too long (98 > 79 characters)
Line 107:80: E501 line too long (88 > 79 characters)
Line 108:80: E501 line too long (99 > 79 characters)
Line 109:80: E501 line too long (100 > 79 characters)
Line 112:80: E501 line too long (88 > 79 characters)
Line 113:80: E501 line too long (91 > 79 characters)
Line 116:80: E501 line too long (90 > 79 characters)
Line 128:80: E501 line too long (97 > 79 characters)
Line 130:80: E501 line too long (97 > 79 characters)
Line 134:80: E501 line too long (105 > 79 characters)
Line 140:80: E501 line too long (91 > 79 characters)
Line 150:80: E501 line too long (120 > 79 characters)
Line 151:80: E501 line too long (119 > 79 characters)
Line 152:80: E501 line too long (117 > 79 characters)
Line 153:80: E501 line too long (123 > 79 characters)
Line 154:80: E501 line too long (122 > 79 characters)
Line 155:80: E501 line too long (120 > 79 characters)

Comment last updated at 2021-08-31 05:21:42 UTC

[vardaan-raj]

I have just updated the registry to include the new hash values for the modified png images, can you help as to why the checks are failing??

[vardaan-raj]

I have updated each individual modified png file in the registry with the new checksum value

[vardaan-raj]

Can someone please update me on what to do next??

[grlee77]

Can someone please update me on what to do next??

There are a mixture of real failures here and ones that are due to the fetcher comparing hashes in this PR to data that was fetched from main. Those SHA256 errors will resolve themselves if we merge.

There is one file, no_time_for_that_tiny.gif whos SHA256 changed, but it hadn't updated in the table

However, there are also a couple of more subtle errors here!

Specifically the "mode" of several of the PNG files (see Pillow docs on mode) has changed. Two of these changes cause test suite failures:
1.) logo.png was RGBA, but the compression here dropped the alpha channel (because it was all ones). However there is a test that explicitly checks that this file has 4 channels.
2.) palette_gray.png had mode P (palette) before, but now has mode L (uint8 grayscale).

Those are the only two mode changes that cause a test suite error, but there are others that got changed from RGB to type L or 1 as well:

measured mode changes

bw_text.png  RGB -> 1
chessboard_GRAY.png   RGB->I
horse.png   RGBA->LA
logo.png  RGBA->RGB
palette_gray.png  P->L
phantom.png   RGB->L

I am not sure we should be making any of those changes even if they are not causing a test suite error.

Modes were determined via navigating to the data folder and running the following script:

from glob import glob

from PIL import Image

img_files = sorted(glob('*.png') + glob('*.gif'))
for f in img_files:
    print(f, Image.open(f).mode)

[vardaan-raj]

I have updated the sha256 for no_time_for_that_tiny.gif in the registry

[vardaan-raj]

What's the next step?

[grlee77]

I think this is okay now. My only question is if we should be even more conservative and not change any of the files under skimage/data.

This one will not pass the CI tests given how the data gets pulled from main so the SHA256 is going to mismatch until we merge this.

[grlee77]

What's the next step?

I have approved it now. Let's see if we can get a review from another maintainer before merging.

[stefanv]

I don't think we can make this change, unless we keep the old copies in the repository as well (otherwise older versions of scikit-image won't be able to fetch their data). So, as much as I appreciate the idea behind this PR, I think we'll have to close.

@grlee77 Happy to discuss if you think this is too conservative.

[grlee77]

I don't think we can make this change, unless we keep the old copies in the repository as well (otherwise older versions of scikit-image won't be able to fetch their data).

Hmm, fetch points to the version-specific branch. Those release branches would not be modified by this, so it should still work after the change. I guess I did not consider what the behavior was prior to the introduction of pooch, though? Is that what you are referring to? Overall, agree that this may not be worth the risk of breaking things.

[stefanv]

@grlee77 If you think the change is worth it, that it won't cause problems (I was thinking of the registry itself, but sounds like that's not a real concern), and you'd like to shepherd it through, please go for it.