What re-saving and screenshotting do to a submission

Yes - a screenshot or a messaging-app copy can change a score, because each step re-encodes the image and discards detail the original had. The subject did not move, but a rating tool scores the degraded file it received, not the photo you took.

What happens on the way through

Sending an image through a messaging app usually recompresses it, often at a lower quality setting than the original and frequently at a lower resolution too, to save bandwidth. Taking a screenshot of a photo displayed on a screen adds another full re-encoding pass on top of whatever compression the original already had, plus whatever the display and the screenshot tool did to colour and scale along the way. Each of these steps is lossy - detail that a compression algorithm judges unimportant gets discarded, and it does not come back on the next pass. Do this two or three times, screenshot of a screenshot, and the artefacts compound.

Why the score can move because of it

Compression artefacts show up first in fine texture and sharp edges, which are exactly the regions more pixels stop helping and more processing starts hurting once they are already degraded. An image that has been through a messaging app and a screenshot and a re-save carries visibly less real detail than the source file, even though its file size or resolution number might look unchanged. A rubric reading detail-adjacent axes is reading a re-encoded approximation of the original photo, not the original photo, and the tool has no way to know the difference - it scores what it received. Image models are measurably sensitive to this: Dodge and Karam (2016) tested four state-of-the-art classifiers against blur, noise, contrast and JPEG compression and found them "susceptible to these quality distortions", with blur and noise doing the most damage.

The protocol rule

Submit the original file, straight from the camera, not a copy that has passed through a chat thread, a social app or a screenshot first. If a photo has to travel between devices, use a method that keeps the file intact - a cable, a cloud folder, an unedited export - rather than whatever messaging app happens to be open. This sits alongside every other item in a comparable submission: the file itself is a variable, and re-encoding it changes the input the same way a different crop or a different light source would.

Why a screenshot is worse than a re-save, specifically

A straight re-save at lower quality is one lossy pass: the compression algorithm discards detail once, according to whatever quality setting was chosen, and the result is a smaller but predictable degradation of the original. A screenshot is at least two passes stacked on top of each other, and they are not the same kind of loss. The first pass is whatever compression the image already had before it was displayed; the second is the screenshot tool re-encoding what the screen showed, which introduces its own artefacts on top of the first set, plus whatever scaling happened between the image's native resolution and the screen's resolution, plus, on some platforms, a colour-profile conversion the screenshot tool applies without asking. None of those individual steps is dramatic on its own, but they compound, and a screenshot of a screenshot - which happens more often than it should, usually via a forwarded message reopened and re-captured - can lose a surprising amount of the original detail in two clicks.

What is a related but different problem

Video frames extracted from a clip carry their own, larger version of this same degradation, compressed harder than a still photo typically is - that gets its own treatment rather than a mention here. Low native resolution is a related but distinct issue from re-encoding: one is about how much detail the sensor captured in the first place, the other about how much of that detail survived transmission.

What is actually being scored underneath this

The model reading a submission has no concept of "original" versus "re-saved" - it processes whatever pixels arrive, and re-encoding changes those pixels before the model ever sees them. This is a file-handling question, not a camera one, which is why the gear side of a setup is less relevant here than how the file travels afterward.

Away from the tool entirely

The same rule holds if the image is going to a human judge rather than a model - a heavily compressed screenshot looks worse to a person too, for the same reason a model reads less detail in it. Rate Cock's photo guide asks for the original file rather than a forwarded copy, and the reasoning transfers to any tool a photo might end up in.