The SSF model encountered issues during the reconstruction of the image.

[silidada]

Thank for your great work ! When I remove the note at the line of 264 picture below to use the API of decode, I get the reconstructed picture with mosaic patches, and I do not know what something wrong causing that, can you provide me with some help? Thanks again!

[theXiangCode]

I also had a similar Mosaic problem using other image compression networks. Have you solved it

[YodaEmbedding]

Please provide the input image file and model name / settings and commands/code used.

Consider setting torch.backends.cudnn.deterministic = True, or other PyTorch determinism tricks.

[theXiangCode]

Thanks for your suggestion, I also set this parameter, but unfortunately this Mosaic situation still occurs, and as the resolution of the input image decreases, the probability of this Mosaic situation will decrease. Do you know what the cause of this is

[theXiangCode]

this is the code. This model is pre-trained using a model bmshj2018-hyperprior quality is 6 I was dealing with a very large image in SVS, about 100,000 × 100,000 pixels, so every time I used the network to deal with 1024×1024, but unfortunately, about 10% of the image appeared this Mosaic situation, resulting in my overall poor look after decompressing. Do you know the solution? Thank you very much

[YodaEmbedding]

Each mosaic block is probably happening because of some improperly decoded element of y. For instance, if an element of y is usually ~0, and we accidentally decode a value of 1000, it's going to cause catastrophic effects within a surrounding field of influence as it expands during g_s upsamples.

Why does an element get incorrectly decoded? Not sure. A usual culprit is that the encoder and decoder are "out of sync", which is where determinism can help.

Non-deterministic reductions

Also, the current implementation may not produce the same results on different devices due to non-deterministic hardware computations. Thus, encoding on device A and decoding on device B may not work. Even the same device may fail if it doesn't do vector floating point computations deterministically. For instance, the result of a reduction sum depends on the reduction order, which may vary depending on which compute units finish first, the reduction tree enforced by a hardware unit, or other reasons.

(0.1 + 0.2) + 0.3   !=   0.1 + (0.2 + 0.3)

Evaluating each side gives different results:

>>> (0.1 + 0.2) + 0.3
0.6000000000000001

>>> 0.1 + (0.2 + 0.3)
0.6

...floating point addition is not exactly associative!

If the pre-reduction values are bounded (e.g. by rounding to lower-than-hardware 2p-bit precisions), then determinism becomes more likely:

def Q(x, p=4):
    return (np.array([x * 2**p]).round().clip(-2**(2*p), 2**(2*p)) / 2**p).item()

(Q(0.1) + Q(0.2)) + Q(0.3)   ==   Q(0.1) + (Q(0.2) + Q(0.3))

>>> (Q(0.1) + Q(0.2)) + Q(0.3)
0.625

>>> Q(0.1) + (Q(0.2) + Q(0.3))
0.625

On hardware with IEEE-754 32-bit floating point, a 3-item reduction sum should always be deterministic with p=4. Proof left as exercise to reader.