feat: init img convert & compress for gallery view

[kunfang98927]

Please note that now before running python manage.py import_instruments, you should first run python manage.py download_imgs.

There are a few changes in this pull request:

• Add pillow dependency for image conversion and compression (by running poetry add pillow);
• Create a new Django management commands in download_imgs.py. By running python manage.py download_imgs, it will: (1) download all original instrument images (one image for each instrument) from wikimedia urls into vim-static volume; (2) convert original images to .png format and store them on UMIL server; (3) compress original images and store the smaller version as thumbnails on UMIL server;
• Modify import_instruments.py command: replace the old image urls with current image paths;
• Add thumbnail field in Instrument model;
• Create additional migration file migrations/0002_instrument_thumbnail.py;
• In gallery view HTMLs, replace the old image url with current thumbnail url with static template tag;
• Add __init__.py under VIM/apps directory to fix pylint error: No name 'apps' in module 'VIM' Pylint(E0611:no-name-in-module);
• Adjust importing order in all management commands;

Resolves: #138

[dchiller]

Ok, @kunfang98927... the changes look great, but there's one more thing I realized as I was running this locally about the location of the image files. Sorry I didn't catch it earlier.

1. When you are downloading the images and saving the original and thumbnail to the filesystem, you are doing so within the bind mount ./web-app/django:/virtual-instrument-museum/vim-app (see line 11 of docker-compose.yml). This means that you'll notice that when you run download_imgs, the images show up outside the container within the web-app/django/ directory (eg. in a place recognized by git). We don't want the images committed, so that path could be gitignored in some way. On the other hand, I wonder if we really want the images to exist in the bind mount at all. You could save them somewhere within the vim-static volume (/virtual-instrument-museum/static within the app container) and then they wouldn't appear in your working directory but would be saved across container builds. Let me know if that doesn't make sense.
2. With the Django static files app, rather than store the path to the image prepended with settings.STATIC_URL, the canonical approach is to use the static template tag. You can see this in use in the same img tag in the template that you modify in the onerror parameter: <img src="{{ instrument.thumbnail.url }}" class="card-img-top rounded p-2" alt="instrument thumbnail" onerror="this.onerror=null;this.src='{% static "instruments/images/no-image.svg" %}';" />. The benefit is that we then aren't hardcoding any internal links (one change to settings and we could serve all our images from a different location). If you save the image url without settings.STATIC_URL prepended, and use the static template tag, this should work. (My comment in the earlier review suggested the opposite of this 🤦 )

[kunfang98927]

Thank you for the comments.

1. When you are downloading the images and saving the original and thumbnail to the filesystem, you are doing so within the bind mount ./web-app/django:/virtual-instrument-museum/vim-app (see line 11 of docker-compose.yml). This means that you'll notice that when you run download_imgs, the images show up outside the container within the web-app/django/ directory (eg. in a place recognized by git). We don't want the images committed, so that path could be gitignored in some way. On the other hand, I wonder if we really want the images to exist in the bind mount at all. You could save them somewhere within the vim-static volume (/virtual-instrument-museum/static within the app container) and then they wouldn't appear in your working directory but would be saved across container builds. Let me know if that doesn't make sense.

Yes I think downloading to vim-static volume makes sense. So for the download_imgs.py, I'll change the OUTPUT_DIR to

OUTPUT_DIR = os.path.join(
    settings.STATIC_ROOT, "instruments", "images", "instrument_imgs"
)

2. With the Django static files app, rather than store the path to the image prepended with settings.STATIC_URL, the canonical approach is to use the static template tag. You can see this in use in the same img tag in the template that you modify in the onerror parameter: <img src="{{ instrument.thumbnail.url }}" class="card-img-top rounded p-2" alt="instrument thumbnail" onerror="this.onerror=null;this.src='{% static "instruments/images/no-image.svg" %}';" />. The benefit is that we then aren't hardcoding any internal links (one change to settings and we could serve all our images from a different location). If you save the image url without settings.STATIC_URL prepended, and use the static template tag, this should work. (My comment in the earlier review suggested the opposite of this 🤦 )

Sure. I'll replace the thumbnail url in template with the one using static template tag:

<img src="{% static instrument.thumbnail.url %}" ...