@fgrieu found time to look at your scans, edited my answer.

@MeirMaor: many thanks. The results you give seem good and resonable, and I have no doubt about them. But do I have very much doubt about "So now we can apply any error correction step (e.g Reed solomon) we will just take the decoding step (didn't actually do this) and we should get the same output from either image with high likelyhood", because the images have not been thru a suitable encoder.

Standard ECC does get a stable output, with certainty, if some bounded number of bits change in the input; but that's only if the input has been thru an encoder. This demonstrably generalizes to any non-trivial function when we keep "with certainty" and don't restrict the input.

I have no proof or even articulated argument for impossibility when we allow some percentage of error or/and restrict to inputs that are meaningful images processed as you did, but I'd be extremely surprised if Reed-Solomon was adequate.

Let's have an alphabet of valid sequences each with hamming distance at least 2k from other. Take two sub sequences of arbitrary data with distance less than k between them. For each of the pair pick the nearest valid sequence. Obviously we will pick the same valid sequence for each.

@MeirMaor: I agree with the above. But that's not applicable to the problem at hand, I believe. The issue is there exist inputs that are <9k/8 from any two subsequences, and if we change k/3 bits in these inputs we'll get from one outcome to the other more often than not. ECC avoids this at the price of an encoding step, which forces the input to be far from problematic area.

I'm not stating there is no solution to the problem I asked (on the contrary, I think that's moreless the problem "robust fuzzy extractors" are meant to solve, and I'm ready to accept they do in encryption, by adding their "helper" or whatever you call the FEC data as a header of the ciphertext).

I state I know no way to turn an image into a key for a normal cryptosystem like AES-CRT or AES-GCM, and still get it to work reliably. And I very much doubt that the process realign/subsample/quantize/normal ECC decoder/hash will do it, because the ECC decoder is intended for data that went thru an encoder before errors occur.

@MeirMaor : I added an update to the end of the question, with link to the scans (that you have) and a slightly more detailed description of what I believe they can help determine.

Yes, I see my error, it's the same trouble in qunatization. Even if the maximal distance was 5% That difference can stil be close to the boundry between two of the discrete choices and the same problem arives also with the distance between vectors. We can apply transformations which reduce the chance of error.

Each transformation we lose information and reduce chance of error, If we start with 6% of bit error. We can reduce it but indeed if we need a lot of information the chance of getting at least one error grows rapidly as we increase data, I don't have proof but indeed suspect you are correct and it's not possible

@Meir Maor: great that we can get an agreement thru this exchange! I'm thinking of making a slightly different question, strictly focused on making a key for a traditional cryptosystem, from image scan, stable enough; with the question asking for proof of impossibility (or refutation).

I need to first devise a precise statement, and perhaps make more scans. It's not as simple as making a set of 5 images as I did, because it's possible to make an alg that pass this test, either with little entropy in the output, or by embedding a little data extracted form the images (perhaps thresolds).

All of the operations I suggested, including resizing and quantizing can all be seen as picking the nearest value from some "valid" values with some distance metric. But I can't prove(but suspect) this is all we can do.

All of these have the same boundry issue, there is a certain chance our diff will be on the boundry as we take things farther apart the chance of being on the boundry is reduced but we also group together more different values and lose more information. This is linear. The reduction of possible values and the reduction in error rate is the same.

If we want 128 bits correct with likelyhood 90% we need a per bit error rate of less than 0.1%

If we start with 6% we will need to reduce that 60X

@Meir Maor: I agree, and I have nothing better (system closer to work, or argument of impossibility) to propose with much confidence.

In this case since the original bits are far from perfectly random, we will need much more than 128 bits. I don't know how to quantify this.

[above edited]

@Meir Maor: FYI, you should have the ability to edit your own comments (fixing typos), within 5 minutes or so they have been first posted, by left-click on the down-pointing arrow that pops when the cursor is on the left of the comment. That also adds a pencil icon. My own comments are littered with these!

When I go over the 5mn mark (which mods can do), I try hard that whatever I add/change keeps the intended meaning, and does not change the meaning too much.