Open GoogleCodeExporter opened 9 years ago
Since part 1 uses full-sample symmetric wavelets, the symmetric border
extension operation commutes with the transform operation.
So, if S is the symmetric extension operation, F is the forward transform, and
R is the reverse transform, then we have the standard requiring
Decoded Image = R(S(F(Original Image)))
Because S and F are commutative, and S * S = S, we get
Decoded Image = R(S(F(S(Original Image))))
So, we must use the symmetric extension in the forward transform as well.
Therefore, if my reading of the standard is correct, we should not be clamping
the image at the border, as we are doing in the above macros. We should use
symmetric extension.
Original comment by boxe...@gmail.com
on 20 Dec 2014 at 3:07
This being related to the standard, i'll cc antonin.
Original comment by m.darb...@gmail.com
on 20 Dec 2014 at 3:15
By the way, this is not a conformance issue after all: encoder conformance
relates completely to the syntax of the code stream, and not the encoded
pixels.
See ISO/IEC 15444-4 Annex F.1
http://www.openjpeg.org/conformance/T.803e.pdf
Nevertheless, clamping at the boundary still does introduce artifacts at the
boundary. So, this is not a desirable feature;
Original comment by boxe...@gmail.com
on 21 Dec 2014 at 5:05
Original issue reported on code.google.com by
boxe...@gmail.com
on 18 Dec 2014 at 9:35