[FEATURE] Improve local image handling

[infinia-yzl]

Is your feature request related to a problem? Please describe.
Locally uploaded files are stored as blobs that only persist temporarily. This is an intended limitation of browsers where files are stored as blobs for security reasons. As a result, users lose their uploaded images when they refresh the page or return to the application in a new session, disrupting their workflow and requiring them to re-upload all images.

Describe the solution you'd like
Implement a flexible image re-linking system that allows users to easily restore their uploaded images across sessions. The solution should:

1. Store metadata about uploaded images (filename, id, content) in localStorage.
2. Provide a user-friendly interface for re-linking images in bulk.
3. Use filename matching to automatically link selected files to stored items.
4. Allow users to select multiple files at once for efficient re-linking.
5. Update preview images in real-time as files are re-linked.
6. Maintain the original item data (content, id) while updating the image reference.

Describe alternatives you've considered

1. Storing full image data in IndexedDB: This was considered but rejected due to potential storage limitations and performance issues with large datasets.
2. Using a server-side solution: While this would provide persistent storage, it goes against the project's goal of maintaining a client-side only application.

Additional context
This feature is crucial for maintaining a smooth user experience in our tier list application, especially for users who regularly work with large sets of custom images. It aligns with our goal of providing a flexible, user-friendly interface while working within the constraints of client-side web applications.

Potential Impact
This feature would significantly improve the user experience by:

1. Eliminating the need for users to re-upload all images after page refreshes or in new sessions.
2. Reducing frustration and time spent on image management.

Open Source Acknowledgment

• I understand that this is an open-source project maintained by volunteers. While the team appreciates and will
  consider all feedback and feature requests, I acknowledge that my suggestion may not be implemented if it doesn't
  align with the project's goals, resources, or priorities.

[staff0rd]

Firstly, kudos for making this, and, making it open source.

Secondly, i'd like to contribute to solving this particular issue, mostly for selfish reasons: I came back to the site the next day after previously uploading 36 images and found all images broken. Re-uploading the same images (same names) doesn't appear to resolve this, so, it appears the list is broken with any new session and/or refreshing. I intend to work on the same tier list over multiple days, so I don't want to start from scratch each day.

Proposals:

1. I could implement (or fix?) functionality where re-uploading the same named image fixes a broken image or;
2. I could implement IndexedDb for image storage. I note your consideration of it above, but question how you arrived on it - MDN suggests the limit is disk based, ultimately this would probably be my preference.

[staff0rd]

If the binary <-> string conversion is an issue with IndexedDb i ponder whether this is an option to cache the binary.

[infinia-yzl]

Hello, and thanks for your kind words and interest in contributing to the project!
Yup, there are multiple ways to tackle this, each with their own pros and cons.

If I remember correctly, my main assumption & worry with IndexedDB was about cache size. Lots of big images across many tier lists could eat up a ton of space (if it stored the images).

Super rough example:

36 images * 10MB = 360MB per tier list
Total storage = 360MB * n tier lists + y original folder sizes

Of course, the app could shift the responsibility to the user to keep the cache size small, or just be fine with growing cache sizes.

However, I was thinking of re-linking images from the same path & device. It would store the paths instead of the whole image. At runtime, it would just fetch the image, only keeping the folder info (assuming the user doesn't move or delete the images).

What do you think?

EDIT: Compressing the uploaded images before storing into IndexedDB could be a solution as well, although the cache would still grow overtime.

[staff0rd]

10mb per image seems extreme to me - on the site it looks like they're displayed 80x80. Even uncompressed images of that dimension are orders of magnitude less than that.

I'm not sure that the cache growing over time, due to multiple tier lists, is an issue either. If I had many tier lists I'd probably start to become more annoyed they could only be accessed via a single device/machine ;)

If an 80x80 lossless PNG, converted to base64 is ~5kb - then 1,000 of those is 5mb...

[infinia-yzl]

I don't disagree. However, currently there are no limitations / handling on the upload file size, so I think making it more deterministic would be ideal. Feel free to experiment.