Does anyone know if JPEG XL encoders can be prone to the infamous JBIG2 "Pattern Matching & Substitution" region-reuse issue, that so badly affected Xerox copiers?

https://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning

#JPEG #JPEGXL #JBIG2 #Xerox

Xerox scanners/photocopiers randomly alter numbers in scanned documents

Xerox scanners/photocopiers randomly alter numbers in scanned documents Please see the „condensed time line“ section (the next one) for a time line of how the Xerox saga unfolded. It for example depicts that I did not push the thing to the public right away, but gave Xerox a lot of time before I did so. <iframe width="700" height="394" src="https://www.youtube.com/embed/c0O6UXrOZJo" frameborder="0" allowfullscreen></iframe>

D. Kriesel
@sundew Not with the libjxl encoder. But for any format you can in principle make a bad lossy encoder that makes bad choices...

@wb Thank you so much for the response!
I appreciate the sentiment.

Thinking specifically about pattern matching and substitution, I see from a features list that JPEG XL supports breaking the image into tiles... but does the format even allow for those tiles to be re-used, as JBIG2 does?

@sundew There's a coding tool called Patches that allows you to basically copy a pattern to several places in an image - it is used for things like letters in text or repeated icons etc. But the residual error is still encoded, there is no 'fuzzy matching' being done like in some lossy jbig2 encoders where the near-match is the only thing that gets encoded, there is always a residual image too.