I’ve read about everything I can find here on this subject and I’m still a little confused about what works best for identifiers/researchers. My two basic tools are a DSLR and an iPhone SE. I post-process all my photos, including the iPhone shots, in Photoshop before posting as observations. I do this mainly to improve exposure and tone and to crop around small or faraway subjects. I use only the photos that are in sharp focus. I’m learning that for some taxa, closeups from different angles are critical. For example, there are 12 species of Fritillary butterflies (Boloria) in Alaska and the diagnostic features are likely to be on the ventral side of the wings, so that’s what I’ll be trying to capture in the future. I’m also not especially tech-savvy and struggle to comprehend some of the terminology used in digital photography, so I hope you’ll bear with me.
I once learned that 72dpi is sufficient for web viewing, but is that true for more difficult IDs? Here’s an example: let’s say I take a 300 dpi photo of a Boloria and crop it to 2048 pixels (or less) on each side. I can save it at Photoshop’s low quality (1) =110k or maximum (10) =700k. Or I can take the same crop and downsize it to 72 dpi and then low quality (1) =47k and max is (1) =115k. Either way, the image is under 1.0 MB so not all that big compared to the original, uncropped 3.83 MB photo. Should you, as the viewer, want to enlarge the image in order to see details, what would you prefer? (And no, I don’t have a macro lens – yet. When I’m outdoors and potentially running into everything from tiny flowers and fast-moving butterflies to giant moose, it’s too hard and time-consuming to carry all those lenses).
Thank you so much for the help.
A cropped image of 3 to 4 megs would be desirable for butterfly/moth/insect identification. Uploading images at a size of 47K to 115K would yield really small, almost unusable images for good ID. But like you, I’m not very tech savvy either, and I use a small point-and-hope camera for uploads.
Most people do not understand this. The ideal is to crop to a square maximum of 2048 x 2048. This ensure there is no change within iNaturalist. And the observations shows as intended within the square grid display. It a photo is cropped say 3000 x 2000 (or 6000 x 4000 or more for most cameras) this will be reduced to the longest edge 2048 but the shortest edge is significantly reduced and perhaps the relevant area of the moth or butterfly or flower is too. This for example means that it may no longer be possible to count the number of stamens in a flower. If I cannot do that it would be impossible to ID that correctly.
Size
Resolution in dpi is not a meaningful concept to iNaturalist images, size in pixels is everything. If the image is not square, the longer out of width and height is what matters. Since iNaturalist scales down anything larger than 2048×2048, you can’t overload its storage capacity with huge file sizes. At most you can temporarily inconvenience its data plan as it receives your photos, by the same amount that you use up your own monthly data as you send them. So,
If after cropping, your photo is 2048×2048 or smaller, send it as is.
If it is larger, scale it so the longer side is 2048 pixels - this is what iNaturalist will do to it anyway. Have you lost any details that identifiers will need? Then crop it smaller so it will be scaled by less.
If you want to minimise iNaturalist data use, send your scaled photos from step 2.
Quality
I’d be very wary of using low quality file export settings. The compression artefacts introduced can make it hard to see details like hairs and scales that identifiers may need.
Even the original 3.83 MB file in your example is not particularly big in terms of file uploads in 2023. I would only get concerned if your files are routinely over 10 MB. While iNaturalist’s data capacity is not infinite, it is pretty big.
So where does the 72dpi number come from?
It is a good rule of thumb, for images that will be displayed on web pages in fixed size, like backgrounds and logos. However, iNaturalist makes it easy to click on a photo to zoom into it, so the size to think about is the size when zoomed in. The arithmetic for this in dpi terms is confusing, so just think in pixels.
Future sizes
While the 2048 pixel number was in use at the date I posted this, in future it may be increased if storage is cheap enough and high resolution screens are common enough.
My default setting for images is 300dpi and resized to around 10 inches on the longest edge and in Photoshop saved with a quality setting of 10 out of 12.
Obviously, if the image is heavily cropped it’ll be smaller than that on the longest edge.
This results in an image that’s between 1-3 MB, depending on the amount of color variation and detail in the image, and provides plenty of detail for identification without taking up too much space or overloading the capacities of iNat.
This is also usually sufficient for both print and web viewing, unless I’m printing it as a poster.
Others have said that the default iNat dimensions are 2048 pixels on each side, which is about 6.8", so are your photos getting compressed to fit that size?
Welcome to the forum! I’m a new user myself so I have SO many questions (many answers are offered in older topics, too).
Many posts in the forum on this topic mention that iNat reduces the dimensions to a 2048 pixel square so that’s what I’ll be aiming for. Thank you for clarifying in everyday language, the difference between resolution and dpi, which has been confusing me for a long time, as well as Photoshop quality.
Yes, cropping before uploading is going to be best. iNat doesn’t have built in image-editing tools, though there have been feature requests for these (but doesn’t seem to be a priority).
They are definitely being down-sampled to 2048 pixels in the longest dimension, which you can prove by downloading the “original” (not) photo from any of your observations. That’s why it’s super important IMO to
Every time a JPEG is re-saved (like after downsampling), it is also re-compressed. By default re-compression is at minimum lossiness (but it adds up), meaning that you could theoretically end up with a larger storage-size file on iNaturalist than your 3000-pixel but more compressed (quality 10 out of 12) original.
So there is no point in trying to “save space” on iNaturalist’s storage. If you are sending them an image larger than 2048 pixels on one side, and if storage space at your end is not a concern, you should always save JPEGs at maximum quality at your end (12 out of 12, or the equivalent in other software). When iNaturalist downsamples it to 2048 pixels, and applies whatever compression setting it uses when re-saving (hopefully the minimum compression = maximum quality), you are going to end up with about the same-sized file at iNaturalist’s end, but with better or worse detail depending on how much compression (quality-loss) you used at your end.
I always use the highest resolution available to take photos, this gives me room to manipulate after.
Cropping to ~35% (by width or length) target and ~65% environment usually gives the best artistic effect.
Cropping to over 50% target gives the best photo quality of uploaded photos on iNat. It saves some space as well on my disk - the 1 TB backup storage is filling up quick,
I think resampling is for the initial display only, opening the photo in a separate tab sometimes gets me really large images, def more than 2K by 2K pixels.
That’s an interesting concept to crop the photos to square. I always make sure that I take images in both vertical and horizontal formats, and reduce the dimensions to 2048 on the longest edge. But if I were to think like you and do a square crop then would I not need to do both the vertical and horizontal formats? I’m trying to get my head around this concept!!
It depends on your subject matter and the situations you find yourself in, doesn’t it? If it’s something small like a bee, flower, or mushroom, you can probably frame the shot so you can crop it into a square. If it’s a larger animal and you want to include some habitat, then a landscape or vertical shot might be better.
Exactly. The idea of always cropping to square makes little sense to me. The crop ratio is determined by the shape of the subject, and/or what else is useful to include in the shot for context. Since the longest edge will always be limited to 2048 pixels on upload, by insisting on a square crop you are then increasing the shortest edge from whatever it would have been otherwise, up to also being 2048 pixels. And all you are achieving with that is to include additional irrelevant background data which only unnecessarily increases the file size, and thus energy usage and storage costs. It may also make it more difficult for the machine learning algorithm to correctly pick out the subject.
Be wary of opinions. If you wish to understand the reality, then better to go do your own tests comparing different compressions and resolutions. It seems pretty clear to me that the current approach of significantly compromising on resolution while using only minimal compression (i.e. excessively high jpg quality) is sub-optimal in terms of the average resulting ratio of preserved detail to file size achieved. Though in fairness, iNaturalist still does a better job of this than most websites, and it is a bit tricky to come up with a singular approach that works well across the full range of image sizes and qualities that get submitted here. This topic has been discussed in more detail in the thread below: https://forum.inaturalist.org/t/increase-max-image-size-from-2048-x-2048-pixels/13627/
Most views of iNat observations show only a square thumbnail of the first image. If the image isn’t square, the thumbnail just shows the center of the image. Here’s an extreme example:
a photo of a snake that I cropped to show only the snake, and its appearance in the Observations view on the website
I’m not saying you must always crop the first image of an observation to a square, but you should consider what your observation will look like to an identifier looking at a wall of 30 thumbnails that may or may not have enough time and interest to click on each one of them.
This is a very relevant topic, with important repercussions on the workflow of contributors and on the quality and size of iNat archives. I concur that dpi is useless in this context because the photos are not viewed after printing.
The final objective is to submit photos in a rectangular or square aspect, in the JPG format and with the highest quality setting (=lowest compression).
If you don’t want to be surprised by the look of your uploaded photos in iNat, use the sRGB color palette in your editing software in case you want to fine tune, but then you should also care about adjusting the white balance (warm-cold tones) of the photos.
iNat will reduce the resolution of your photo to 2048 by 2048 pixels (if it is larger) during the registration process, which is frequent because modern cameras have high resolution sensors. For instance the maximum photo area on iNat is 4,200 pixels, and my camera produces photos of 32,300 pixels (+/- 7,000 X 4,600).
You can alternatively proceed yourself before submitting the photo by doing a resampling while editing the photo, or when saving it. This allows you to preview the look of the photo on iNat, and evaluate if the critical details for identification are visible.
Since it is possible and often desirable to upload several photos of a specimen, I frequently post first a general view with background info (plants, general environment). To help with identification, I will also post additional photos with different viewing angles and enlargement ratios of the specimen. If I have a single photo, I frequently edit and upload a second copy of the photo, framed more tightly on the area(s) where critical details are located.
