It was the compression format, not the scanner, right? Same would have happened if you store in that format (with the same quality settings etc.) on a computer or smartphone

Not that that helps anyone who's affected, but that situation is more like if you'd have an .aip file, AI Photo storage format, where it invents details when you zoom in, and not a sensor (pipeline) issue

▲

namibj 5 days ago | parent [-]

No they exhibited it in pure instant single copy copying mode.

▲

Aachen 5 days ago | parent [-]

Oh wtf! I had ctrl+f'd the article for cop (to catch "copy" and "copies" and such) to quickly check this but didn't see that. Then I guess I don't remember the root cause of this issue

	▲	namibj 3 hours ago \| parent [-]
		Apparently you were right, mostly. Though it was later determined to be independent of quality setting; the vendor had claimed after the initial findings and having had a lot of time to try and internally reproduce "that factory default settings would be unaffected". I, probably due to phrasing ambiguity in an old TheRegister article on the matter, had mistakenly remembered the temporary storage between scan and print of the copy mode to also had been affected. As there were many situations where one would scan and destroy the original once offsite backup has run, while physical copies would/should often not entail destruction of the original, most of the overall damage/impact would be due to scanning anyways, not copying.