SIMD YCoCg conversion not bit-perfect?

[erikogabrielsson]

Hi,

I have noticed that when the SIMD (both SSE2 and ARM Neon) version of the YCoCg conversion to RGB are used the returned data is not exactly the same as from the "slow" version. Commenting out the SIMD YCoCg conversions result in the same data. Both SIMD version seems to produce the same data (at least for this tile).

Comparison using np.testing.assert_array_equal

Comparing .\test_tile_arm.png .\test\expected_output\testslide_example_tile_3_5_10.png
.\test_tile_arm.png is not equal to .\test\expected_output\testslide_example_tile_3_5_10.png

Arrays are not equal

Mismatched elements: 119446 / 262144 (45.6%)
Max absolute difference: 2
Max relative difference: 0.03333333
 x: array([[[227, 224, 230, 255],
        [225, 227, 229, 255],
        [228, 229, 234, 255],...
 y: array([[[226, 224, 229, 255],
        [225, 227, 229, 255],
        [228, 229, 234, 255],...
----------
Comparing .\test_tile_sse2.png .\test\expected_output\testslide_example_tile_3_5_10.png
.\test_tile_sse2.png is not equal to .\test\expected_output\testslide_example_tile_3_5_10.png

Arrays are not equal

Mismatched elements: 119446 / 262144 (45.6%)
Max absolute difference: 2
Max relative difference: 0.03333333
 x: array([[[227, 224, 230, 255],
        [225, 227, 229, 255],
        [228, 229, 234, 255],...
 y: array([[[226, 224, 229, 255],
        [225, 227, 229, 255],
        [228, 229, 234, 255],...
----------
Comparing .\test_tile_sse2.png .\test_tile_arm.png
.\test_tile_sse2.png is equal to .\test_tile_arm.png
----------

Tile produced using SSE2 SIMD:

Tile produced using ARM Neon SIMD

I´m not an expert on SIMD acceleration, but perhaps there is a over/underflow in the operations?

[Falcury]

Sorry for the late reply!
I am not quite sure what could be causing the discrepancy, and also not sure whether the slow or the fast version is the 'correct' one... Maybe one possibility is that the slow version is using using 32-bit integers while the SIMD version keeps everything at 16-bit. Over/underflow could indeed be the difference. Could you try to change the slow version to 16-bit integers and see if the result changes?

e.g. by changing it to this:

static rgba_t ycocg_to_rgb(icoeff_t Y, icoeff_t Co, icoeff_t Cg) {
    icoeff_t tmp = Y - Cg/2;
    icoeff_t G = tmp + Cg;
    icoeff_t B = tmp - Co/2;
    icoeff_t R = B + Co;
    return (rgba_t){{{ATMOST(255, R), ATMOST(255, G), ATMOST(255, B), 255}}};
}

static rgba_t ycocg_to_bgr(icoeff_t Y, icoeff_t Co, icoeff_t Cg) {
    icoeff_t tmp = Y - Cg/2;
    icoeff_t G = tmp + Cg;
    icoeff_t B = tmp - Co/2;
    icoeff_t R = B + Co;
    return (rgba_t){{{ATMOST(255, B), ATMOST(255, G), ATMOST(255, R), 255}}};
}

At least the differences are minor, so it shouldn't have much visual impact.

[Falcury]

@erikogabrielsson Do you maybe have an update on this, or maybe a test case? Last time I tried this I could not reproduce the difference.

[erikogabrielsson]

@Falcury
Sorry for missing to update on this. If I change ycocg_to_rgb and ycocg_to_bgr to your suggested lines I get the same result for the test tile (level 3, x 5, y 10 in testslide.isyntax) on my windows pc as on my arm64 mac.

[Falcury]

@erikogabrielsson Ok, in that case I guess that's probably the cause. I'll apply the change in the code.