On image upload, create smaller version of image for thumbnails

[dchiller]

In discussion of #53, we'll want to create smaller versions of uploaded images for quick loading in a gallery view.

[kunfang98927]

I'm currently working on this issue. Before I push the code, I'd like to know if you have any comments. @dchiller @fujinaga

What I did is to create a new Django management commands script VIM/apps/instruments/management/commands/download_imgs.py. So we can run python manage.py download_imgs to execute the image downloading and conversion process. This process includes:

1. Read the startup .csv file to get all urls of images from the image column;
2. Download all images from urls into VIM/apps/instruments/static/instruments/images/instrument_imgs/original/ folder. Here, all images will be converted into .png format when stored;
3. Compress all .png images into thumbnails at a compression rate (say 0.5). Thumbnails will be stored into VIM/apps/instruments/static/instruments/images/instrument_imgs/thumbnail/.

Also, I modified the VIM/apps/instruments/management/commands/import_imstruments.py to replace the image urls with the new path where the images are stored.

[dchiller]

Sounds good to me! My only question (and maybe you have figured this out and it'll be in the code) is how we will use this when users upload images. Are you thinking we periodically run this command on newly uploaded images? Or run it asynchronously on image upload?

[kunfang98927]

Sounds good to me! My only question (and maybe you have figured this out and it'll be in the code) is how we will use this when users upload images. Are you thinking we periodically run this command on newly uploaded images? Or run it asynchronously on image upload?

Thank you for your comments. It's a good question which I haven't think much about. I think there are two cases:

1. For an existing instrument:
   According to the discussion with @fujinaga and @yinanazhou a few weeks ago, we might not need a instrument detail page any more to display any detail for each instrument. We only need to keep our current gallery view to list all instruments' thumbnails. When users click on one instrument, it will navigate to the corresponding wikidata page. The role of UMIL should only be an "Editor". So ideally, we only need to provide an interface (such as a modal window for each instrument) and call wikidata APIs to update new names or images for an existing instrument directly to wikidata, which means we don't need to make any update on our own database.
2. For an instrument which is not in UMIL:
   This case is more complicated because it includes two situations: 1) the instrument is not in UMIL but in wikidata; 2) the instrument is neither in UMIL nor in wikidata. As we currently display a "startup" version of instruments, we haven't synchronized with wikidata. So I think this should be further discussed.

[dchiller]

I think this issue could use some refining in light of the discussions it sounds like you've been having.

What images are being resized? If we aren't storing/updating images in our own database, where are the images that we are resizing coming from and being stored? If they are coming from Wikidata, then are we doing this on-the-fly? Does our photo re-sizer sit between a user and Wikidata, so that when they "upload to Wikidata" through our editor we resize the photo before it get's pushed to Wikidata? If we aren't serving any images, why do we need a resizer anyway?

If we don't know the answers yet to some of these questions, but are pretty sure we'll want to convert images and turn them into thumbnails, then perhaps all we want at the moment is a module to convert and resize images.

Of course, the command you've created could be repurposed at a later time for these other purposes too. In which case, I think just edit this issue for the time being to fit what you've done in your command.

[kunfang98927]

Here are some of my answers. Please feel free to comment.

What images are being resized?

The images displayed in the UMIL gallery view.

One instrument have only one image to display in the gallery view like an "album cover". These images should be stored in the static/ folder as both the original version and the compressed version (thumbnails) by running the commands python manage.py download_imgs. For example, currently we have 262 instruments in our startup csv. So after running python manage.py download_imgs we can store 262 original .png images and 262 compressed thumbnails into static/ folder.

So images as "album covers" should be stored, only one original png and one thumbnail for each instrument.

If we aren't storing/updating images in our own database, where are the images that we are resizing coming from and being stored? If they are coming from Wikidata, then are we doing this on-the-fly? Does our photo re-sizer sit between a user and Wikidata, so that when they "upload to Wikidata" through our editor we resize the photo before it get's pushed to Wikidata? If we aren't serving any images, why do we need a resizer anyway?

Although we only display one image as the cover for each instrument in the gallery view, when clicking on "guitar", for example, users will go to the wikidata page of guitar (https://www.wikidata.org/wiki/Q6607) to view all other images of guitar. These images should not be stored by us. They should only stay in wikidata page.

If a user want to add one image for guitar, UMIL will provide a model window. When the user uploads the new guitar image, UMIL will only need to call the wikidata API to pass the image to wikidata. So here we do not need to store the image.

[dchiller]

These images should be stored in the static/ folder as both the original version and the compressed version (thumbnails) by running the commands python manage.py download_imgs

What are the reasons for storing any images on the UMIL server? There's been discussion in #15 and #105 (maybe other places and in-person, too, of course) about where to store images. If we are storing any images on the UMIL server, then how do we manage synchronization? If I'm uploading an image of a new instrument, what happens?

[fujinaga]

We should store the thumbnails as close to the server as possible so that they can be displayed on the website as fast as possible.
An image of an instrument that are already on Wikidata but without any images on Wikidata, we should keep the original until we put it on Wikidata.
If the instrument is not in Wikidata, we should ask the uploader as much metadata so the we can add it to Wikidata.
In both cases, we should automatically create a thumbnail version and store it where all other thumbnails are.

[dchiller]

Ok, sounds like there are probably many issues that need to be made related to this process.

@kunfang98927 I think you could update this issue to match what you did and then we can review.