Image Architecture

Owned by Mikah Pinegar
Last updated: Sep 19, 2022
4 min read

Introduction

The images are currently all scaled to 4 different sizes: original resolution, 100x100, 200x125 and 250x250. The image names all contain metadata such as crop name, growth stage, owner, and year taken. this metadata is then split out and used in the tool.

Current Folder Structure

– Cover Crop Photos (original resolution) – – 100x100 (100x) – – – – <species name folders> – – – – – – <multiple images> – – 200x125 (x125) – – – – <species name folders> – – – – – – <multiple images> – – 250 (250x) – – – – <multiple images without species folders> – – <species name folders> – – – – <multiple images>

Current JSON Object for Images

{ "Alfalfa": { "Cover Crop": "<crop name>", "Key Thumbnail": "<file name>", "Notes": null, "Directory": "<dir name>" }, ...etc }

I think notes is unused even though some crops do have notes?

Possible Solution 1 (Least Ideal)

  • Existing architecture but in azure blob

    • Split metadata from file name

    • Weird folder structure

    • Use existing JSON object but with URLs instead of dir names

Possible Solution 2

  • Store metadata in a DB table so it doesn’t need to get split out of the file name

  • Store each version of scaled image in azure

  • Have a few routes for returning different amounts of data

    • List images for all species and all resolutions (ex GET /images/all)

      [ { "ccName": "Alfalfa", "thumbnailIndex": 0, "originalResolution": [ { "growthStage": "<stage>", "owner": "<owner>", "yearTaken": "<year>", "imageURl": "<blob url>" }, ...etc ], "100x100": [ { "growthStage": "<stage>", "owner": "<owner>", "yearTaken": "<year>", "imageURl": "<blob url>" }, ...etc ], ...etc }, ...etc ]

    • List images for all species one resolution (ex GET /images/100x100)

    • List images for one species all resolutions (ex GET /images/all/<species>)

    • List images for one species one resolution (ex GET /images/<resolution>/<species>)

Possible Solution 3 (Most Ideal IMO)

  • Store metadata in a DB table so it doesn’t need to get split out of the file name

  • Store only original resolution in blob storage and resize them in the front end

  • Return only original resolution with routes like below

    • List all species (ex GET /images)

    • List a specific species (ex GET /images/<species>)

https://stackoverflow.com/questions/56769299/resize-image-in-the-frontend-javascript-before-sending-it-to-s3

Possible Solution 4 (Second Best IMO If Resizing on Front End is Slow)

  • Store metadata in a DB table so it doesn’t need to get split out of the file name

  • Store only original resolution in blob storage and resize them in the API

  • Return data in a similar way as above