Argh, I hadn't realized the barcode was a Base64-encoded string. Thanks for the report.
Fixing this will break compatibility with applications using that property. The alternatives are worse (adding leica.decoded-barcode, or documenting the property as Base64-encoded), but perhaps we need to make it easier for applications to implement compatibility workarounds for particular versions of OpenSlide.
Also, update the website to document that older versions Base64-encode the property.
I'm not sure I understand your point. If the QR code is stored as pixels, we would expose it in the label associated image, as we do now for several formats. If the contents of the QR code are stored, we would expose them as a string or numeric property. How would a Base64-encoded property help anyone?
In any event, leica.barcode is a vendor-specific property, so we don't need to be concerned with other vendors here.
The terminology I used for decoded was an opaque transformation from the stored representation to a human readable representation (eg. QR code string -> QR decoded string, or base64 -> decoded string). It is very vague and mostly academic debate since it was only a (poor) example to find a solution to the leica.barcode vs leica.decoded-barcode initial issue.
Fixed for 2010/10/01 namespace only. The 2010/03/10 namespace puts the barcode in a different place and I don't have any evidence on whether it is also Base64-encoded, so I haven't changed how those slides are handled. If anyone has a 2010/03/10 slide with a barcode and can verify whether or not the barcode attribute is Base64-encoded, please comment here.