Resizing of photos when uploading - fine details lost

Submitted by Dalegarth5 on

I have recently had 2 records rejected because the verifier considered the photo details were insufficient to confirm identity. So I’ve been looking at how much iRecord resizes photos (as mentioned in user guide). Two recent examples were photos that had been reduced to about 30% of the original width, and supposedly caused the verifier a problem. So I’ve looked at an example from earlier this year, and a photo has been reduced, again to about 30% of the original width. This may well by typical.

A workaround for this might be a photo which ensures a higher resolution than necessary, to ensure when its reduced it’s still usable. But with some insects (e.g.) there often is not the luxury to cover that situation when there will already be (ideally), a top-down, side and front photo, and unless you’re using photo-stacking, there will be parts of the insect that need 2 photos, not one. That probably means no room to cover a critical point anyway. 

Does anyone else find this is an issue?

Comments

Submitted by CristianeForgiarini on Wed, 03/06/2026 - 10:24

Permalink

Sometimes the issue is not related to the size of the image. It is because the diagnostic features required to separate species are not shown on the image. To solve the problem you could use a taxonomic key for guides on diagnostic features or contact the verifier of the record and ask what exactly the record is missing for identification. If you cannot capture all diagnostic features on the image, you can also describe them in 'comment' while including a new record. 

Best regards!

Submitted by Dalegarth5 on Wed, 03/06/2026 - 13:37

Permalink

There may be an element of the problem not being related to size. But on the whole I do use a key, and relate my photos to the salient points in that key. As I said, not all of my photos will be in focus everywhere, and multiple photos are generally required. It is inevitable that some features will become harder to see when a photo is reduced to 30% of what it was. It's too drastic. It is true that I could make suitable comments about other salient point, but it rather defeats the point of uploading photos to illustrate a point! I still maintain that the situation is far from satisfactory, and I have to adopt a strategy of deliberately uploading magnified photos so that a verifier can check the ID properly.

I'm not able to comment on what the future holds with regards to allowing larger photos to be uploaded (server storage issues, I believe, restrict us here), but one small suggestion that may help for the time being (assuming that this situation doesn't pertain to hundreds of records) would be to ask the verifier for their email address so that you can send them the original picture required, hopefully allowing them to confirm your record. One would hope that, as the verifier becomes familiar with you and your expertise, that the requirement for this would reduce over time (although, of course, we cannot speak to all verifier practice here!)

Submitted by Mesh on Thu, 04/06/2026 - 12:58

Permalink

I've raised this more than once and never had a reply from iRecord. Where is the actual information set out regarding uploading images? I've checked the user guide and, as far as I can see, it's not there. As far as I can tell we are restricted to a maximum of four images. I did once find a reference to 2048px in the user documentation but that may be out of date as I've never been able to upload one larger than 1024px on its longest edge. I too sometimes find this restrictive for insect records where a correct ID can rest on tiny details like a fringe of hair below a femur or the relative length of antenna segments.

I could understand the restrictions if they were consistently applied but records imported from iNaturalist seem to have several images attached and some are so large they fill my HD monitor. I just can't get my head around the logic of that?! Why are iNaturalist users treated better than native users of this platform?

Can we have a definitive answer about what images we can upload:

  • how many
  • what is the maximum resolution
  • what file size should we be aiming for
    • is it best to upload without any compression -- if your internet speed will allow that -- and let the system do it
    • is there a file size at which (a sometime brutal level of compression) won't be applied
    • or is the system set to always apply its own idea of the correct level of compression regardless

We are just working in the dark at the moment. Having two levels of compression applied does images no favours at all. Because of the way its algorithm works jpeg compression not only reduces file size but also darkens images.

It's got to the point where I'm intending to log some of my sightings on iNaturalist and just let them feed through to iRecord as the image constraints here is too restrictive.

Submitted by Mesh on Fri, 05/06/2026 - 11:29

Permalink

@OliP_CEH thanks for the quick response. The first GitHub link is very interesting but I see the issue was closed in 2022. Regarding images, images are crucial to recording for most users as they are the only way to get a record verified or build sufficient reputation so a verifier can accept a record as "considered correct" so it would be good to get this issue fixed.

Better, more up to date documentation never hurts open source software/platforms but I realise for most teams it's usually a secondary consideration due to resources.

I've always been struck by the difference in quality of the images on iNaturalist compared to iRecord. I always assumed that iNaturalist just attracted users who were more interested in photography than biological recording and hence had a higher standard of equipment and/or expertise, or that photo enthusiast naturally gravitated towards iNaturalist because it was a slicker platform. I've recently joined Facebook (reluctantly) to access the ID skills of the specialist groups there and been impressed by the standard of many of the images even though Facebook can sometimes be a bit heavy-handed with compression. Perhaps the iRecord platform itself is having more of an impact on this issue than I realised.