You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mirroring this front-end issue, the back-end needs to allow for images to be downloaded instead of displayed just inline.
Also in line with this feature, file names need to be parsed against their file type to ensure the correct file extension is in place; otherwise there are issues trying to open downloaded images. There are 3 main solutions:
Store Image MIME type in separate column
Store Image file extension in separate column
Store image file extension with filename
In this PR I've opted for the 1st option. Options 1 and 2 (Storing an extra column) would also allow us to show the image type in the image info, and allow filtering by type. They also seem more robust than Option 3, which would involve string manipulation to remove and add the file extension back in after image edits.
Between Option 1 and 2, option 2 would be better if we did not want additional enhancements (like viewing and filtering by image type); With Option 2, you would extract the MIME type from the header, convert it to an extension once and store it, where it would be appended to the download url's filename. Whereas Option 1, you would store the MIME type and convert it to an extension everytime an image was downloaded. However, if the filtering/viewing enhancements were implemented it would make more sense to use Option 1.
All of the options are viable however, so any of the implementations work fine.
The text was updated successfully, but these errors were encountered:
Mirroring this front-end issue, the back-end needs to allow for images to be downloaded instead of displayed just inline.
Also in line with this feature, file names need to be parsed against their file type to ensure the correct file extension is in place; otherwise there are issues trying to open downloaded images. There are 3 main solutions:
In this PR I've opted for the 1st option. Options 1 and 2 (Storing an extra column) would also allow us to show the image type in the image info, and allow filtering by type. They also seem more robust than Option 3, which would involve string manipulation to remove and add the file extension back in after image edits.
Between Option 1 and 2, option 2 would be better if we did not want additional enhancements (like viewing and filtering by image type); With Option 2, you would extract the MIME type from the header, convert it to an extension once and store it, where it would be appended to the download url's filename. Whereas Option 1, you would store the MIME type and convert it to an extension everytime an image was downloaded. However, if the filtering/viewing enhancements were implemented it would make more sense to use Option 1.
All of the options are viable however, so any of the implementations work fine.
The text was updated successfully, but these errors were encountered: