@Yosshi999 Could you please check the Nearest8U_vsNonExact failure reason on Win64? That could be near-edge issue we discussed

I thought x2 or x0.5 resizing is bit-exact even if the method is non-exact version because multiplication by 0.5 or 2 will not modify fraction fields of floating point data. But it seems I have a misunderstanding.

@Yosshi999, thank you for the contribution!
Can you, please, implement the following algorithm instead #17068 (comment)?

Can you, please, implement the following algorithm instead

This is completely different algorithm.

Bit-exact implementation should follow this rule and must provide minimal possible difference between:

• bit-exact result of 8U input
• convert to double/floats, run original version on floating-point data, convert result back to 8U.

Without changing of the base NN implementation this should not be called bit-exact.

According to the discussion in #17068, it seems that there are some options:

• Define it as a new method like INTER_NEAREST_PILLOW or INTER_NEAREST_CENTER_PIX_CONVENTION or something. (@catree said we should avoid using the name of a library so I prefer INTER_NEAREST_CENTER_... if this option is chosen)
• Put it into the current implementation of INTER_NEAREST (@vpisarev wants to do this, but @alalek disagrees?)

In these cases above, I will remove the suffix _EXACT and related tests even though this is intended to be bit-exact. I think we don't have to create non-exact version because this doesn't use softfloat so the overhead is not large.

Or:

• Revert to ee74e10 and define it as INTER_NEAREST_EXACT

I will vote for the second one.

I prefer the first option.
On the one hand there is a request for new kind of NN resize in OpenCV library. On the other hand original implementation of NN resize is used internally by several other algorithms already implemented and tuned for existing specific implementation of NN. So changing of NN resize implementation could cause accuracy issues in other pieces of the library. Tracing all such places is an extra effort that is outside of this GSoC project scope, moreover there could be external projects that depend on the existing implementation specific, so such a change could be introduced not early than OpenCV5(or probably even later)

From my point of view BITEXACT part of the algorithm name mean that it produce the same result regardless of the platform it executed on even if the result differs from non-exact implementation, but naming conventions is another thing to discuss. For me it will be enough if there will be a zero tolerance accuracy test for this method with a statement that zero tolerance is important here and that this requirement must not be relaxed.