Document image file size limitations for LF, LD

[alex-larkin]

This issue is solved when:

• [x] The file size limit is known and documented for Chorus
• [ ] The file size limit is known and documented for Language Forge

Is your feature request related to a problem? Please describe. A language project is trying to add large images to their lexical database for archival and revitalization purposes. They appear to add okay in Language Forge, but run into issues when trying to sync with Language Depot. First of all, they need to know what the image file size limits are on these two systems.

Describe the solution you'd like The first step is to determine and document the image file size limitations for Language Forge and Language Depot. The documentation could be placed in the "Known Issues And Limitations" wiki and perhaps somewhere in the image upload GUI.

Describe alternatives you've considered Have a really large limit, or no limit. But that would likely create its own problems.

Additional context I'm making another issue to explore the bigger question of, "How should LF and LD manage image file size limits?"

[alex-larkin]

Ah, we should also consider the usage, abilities, and limitations of other products in this ecosystem, such as FLEx and Webonary.

[alex-larkin]

I added "If sending and receiving, only images under 1MB can be used. " to the Known Issues and Limitations Wiki.

I attempted uploading at 24.7MB image to an entry, but it did not display correctly:

(I tried deleting the other two images and refreshing but to no avail)

How can we determine the file size limit for Language Forge?

[megahirt]

Thank you @alex-larkin for the description in this issue! I think there are a number of things going on that your describe:

• we need to be clear with users what the limitations of LF and LD and FLEx are. To sum it up, audio and images only S/R if they are within the 1MB limit. This should be documented in our Known Issues and LImitations wiki. This is what you named the issue title.

• The 1 MB limit is too small. This should be raised. This is a limitation of the S/R code, not the FLEx or LF application in particular.

• The 24 MB image you uploaded doesn't actually display. This looks like a bug. We should handle large uploads and downsample appropriately.

[megahirt]

@alex-larkin can you go ahead and verify that large images do not display in the browser? At what size do they stop displaying?

[alex-larkin]

Thanks Chris!

This should be documented in our Known Issues and LImitations wiki.

This has been done:

• Senses
  • ...
  • Picture
    • ...
    • If sending and receiving, only images under 1MB can be used.

The 1 MB limit is too small. This should be raised. This is a limitation of the S/R code, not the FLEx or LF application in particular.

I agree. Who is responsible for maintaining this code?

The 24 MB image you uploaded doesn't actually display. This looks like a bug.

Perhaps this is a one-off? Something wrong with that particular image?

Surprisingly, I just got all of these entries to show on my "zzz testing large images" entry in my Quechua Demo project:

Interestingly though, for the larger images, I would upload the image, and then the image wouldn't show. Then I uploaded it a second time, and it would show. This happened consistently, but I'm not sure at which threshold I started seeing that behavior.

Also, I was only given caption fields for the first image. Is that the correct behavior? It seems like each image should have its own caption fields.

We should handle large uploads and downsample appropriately.

Good idea! Just be sure to communicate that clearly to the user though. Perhaps, make downsampling an option that can be disabled.

Thoughts?

[megahirt]

Good idea! Just be sure to communicate that clearly to the user though. Perhaps, make downsampling an option that can be disabled.

@alex-larkin I should clarify "downsample" to mean generate a thumbnail that will load quickly for the user, and they can click to see the full size image in a popup/modal of some sort. The current code probably loads the entire image in the browser then just resizes to a thumbnail size in the entry view. This is really inefficient and generally not good practice.

[megahirt]

@alex-larkin wrote:

Interestingly though, for the larger images, I would upload the image, and then the image wouldn't show. Then I uploaded it a second time, and it would show. This happened consistently, but I'm not sure at which threshold I started seeing that behavior.

Can you open a bug report and then put in the steps to consistently trigger this behavior? Attaching an image that is guaranteed to trigger it would be helpful.

[megahirt]

@alex-larkin wrote:

Also, I was only given caption fields for the first image. Is that the correct behavior? It seems like each image should have its own caption fields.

Oh yeah, caption for each image makes total sense. What does FLEx do? I have no idea. If FLEx has a caption for each image, then we need to fix our model to match FLEx. Open a bug report - thanks!