Platform(s), such as mobile, website, API, other: web specifically
Description of need: Like many iNaturalists, I have a relatively recent mirrorless camera. My camera’s native resolution is 8k pixels, which ends up being ~22-25MB when jpg compressed and uncropped. I would be happy to donate extra $ per month to avoid having to export at a higher compression specifically for iNaturalist and instead just be able to upload directly from my photo application.
Feature request details: I recognize iNaturalist is a nonprofit and always has to weigh costs, which is why there is a file size limit in the first place. I would prefer not to add a whole extra step to my workflow (which is generally about achieving the best possible photo) to bump up the maximum file size higher than 20MB, specifically because most modern flagship cameras will produce a jpg greater than 20MB without cropping, and would instead be happy to donate more than I already do per month to help defray server and storage costs. I recognize that it might make sense to resize server-side, but not having to have a separate workflow specifically for iNaturalist uploads would be a huge timesaver.
Do you not crop your photos at all? I would recommend making a copy of the super large photos as soon as they have been exported from your processing software, and crop those to only include what is necessary. Then upload the cropped versions to iNat and delete them from your computer. All you have left is the full-size version on your hard drive.
If you’re not already doing so, I’d recommend setting up your default jpeg export quality to something like 80%. There is no visible quality loss, and for my 8k shots it tends to change a 20-25mb file down to 10-15mb.
Edit: Also in terms of cropping for iNat, when you upload the file iNat will resize the output to 2k. So if you have a subject that isn’t filling the frame, you’ll be losing a lot of final detail on an 8k file.
Your observations and photos seem to be cc-licensed, which should mean that the storage and bandwidth costs for them are covered by amazon — I wonder if it’d be possible or feasible for iNat to take license into account when accepting uploads and raise the limit if the costs are covered like this? Presumably it wouldn’t cover the compute costs associated with generating smaller versions of the files though, and I have no idea how considerable the processing costs are vs storage and bandwidth.
I often get annoyed when observation photos take a lot of time to display in full size, and I’m wondering if this is due to large file size.
I crop practically all of my photos submitted to iNat, and probably all of them are less-than-1MB copies. Apart from that I think observers should put a certain minimum effort in their submissions if they expect people spending time trying to identify them.
that’s not really why there’s a limit for upload size. the reason is more that iNaturalist isn’t trying to be an image hosting service. even if you upload a large file, iNat is going to resize it down to no larger than 2048px along the longest size. so uploading anything larger than that is just wasting data bandwidth and server processing time to resize the image.
iNaturalist down-samples all uploaded photos to be no larger than 2k pixels in the longest dimension, regardless of the original file size submitted. It also harvests the metadata from the original file submitted, but it does not store the original file, only the downsampled version. So slow display times likely have a lot more to do with Internet bandwidth bottlenecks somewhere upstream.
Slightly off topic, but sometimes the file size doesn’t seem to matter. Do you have an idea why?
For example: I’ve uploaded a picture of a spider recently which I have cropped so the subject fills the frame almost completely. It is about 6200×4200px and has a file size of 42.6MB, yet I had no issue with uploading it onto iNat.
Then sometimes I try to upload images as “small” as 21MB and I get the error message.
not sure how you could have loaded a file larger than 20MB. i just tried ot upload a 20MB+ file, and what i see is that i can bypass the screen’s validation by adding the large photo as a second photo on an observation whose first photo is below the limit. but then when the file is uploaded to the server, the server responds with an error that the file is too large. (@tiwane – you may want to bring this up to the dev team. although the server validation works, what i see is that the upload retry logic kicks in at this point, and the screen ends up trying to load that large file over and over. so ideally, a screen validation that can’t be bypassed would prevent the retrying.)
so even if you found a way to bypass the screen validation, i’m not sure how you would have gotten around the server validation.
you could try loading the same file again, and see if you can get it to load again.
i think that if you load via Android, it will resize for you in the app at least in some cases before it sends the file to the iNat server. but it doesn’t look like you used the Android app here.
it might be possible that your file is stored on your machine in some format that is larger than 20MB, but then when you drag it from, say, your Mac Photos app, it does some sort of on-the-fly conversion that makes the size of the transferred to your browser smaller than 20MB. (the file you loaded appears to be a jpg, and jpg files that are 6000 x 4000 px should generally be smaller than 20MB, i think.)
Perhaps it is an error in the MacOS photos app and how it displays the sizes, but batch loading photos from photos into iNat Upload, I only get those error messages sometimes (funnily enough only on non-stacked images. My stacking software makes the files larger, but I can upload them without problems)
The images on this observation show up as 42.6MB and 44MB in my photos app, for example.
as noted in my previous post, i think it could be on-the-fly conversion. you might have, say, a PNG or TIFF file stored on your machine, and the Photos app might be converting it to JPG on the fly when you drag it to the upload page in the browser (or something like that). (i don’t think a JPG file of your reported pixel size could get anywhere near 40MB.)
Weird. I do have the export of my stacking app set to only jpeg, so I don’t think there would be any other file stored with it. But idk. I’m not very good with computer stuff
