Measurements: "Copy to clipboard" data truncated due to NUL byte in field

[skalteis]

Bug report

Describe the bug
"Copy to Clipboard" for detection results fails due to NUL-Byte in text

To Reproduce
Steps to reproduce the behavior:

1. Create some annotation
2. Run cell detection
3. Open "Show detection measurements"
4. Select one or multiple measurements
5. Click on "Copy to Clipboard"
6. Paste into text editor
7. Result: Headers are copied, data terminates after the content of the "Image" field for the first entry

In contrast: Export to file via "Save" works and shows that a NUL-byte is present in the "Image" fields - which probably interferes with the clipboard functionality

Expected behavior
Content in the clipboard should be identical to the one that can be obtained by saving to text via "Save"

Screenshots
Copy-paste result:

Save to file result, showing NUL bytes in the Image field:

Desktop (please complete the following information):

• OS: Windows 10
• QuPath Version 0.2.1

Thank you & best regards,
Simon

[skalteis]

Ah, as per https://superuser.com/questions/946533/is-there-any-way-to-copy-null-bytes-ascii-0x00-to-the-clipboard-on-windows
the Windows clipboard does not store NUL bytes and treats them as "end of data"...

[skalteis]

Seems to be a problem with the specific image files containing that NUL byte in the image name. It only happens with the Bioformats reader with TIFFs obtained from Olympus software, works well with Hamamatsu's NDPIs with either Openslide or Bioformats. Hmmm.

[petebankhead]

This doesn't look like something I'm going to easily be able to replicate... it seems that perhaps the real bug is including the NUL in the image name?

[skalteis]

Yes, maybe that is something for Bioformats to fix. QuPath could maybe remove the NUL before clipboard export, though. ;-)

[petebankhead]

It could... but I think probably the NUL should be picked up earlier (e.g. when setting the image name).

But in general it sounds like a very obscure occurrence. I'm not sure QuPath should handle it; potentially it could involve littering the code with lots of special cases that shouldn't really occur. In practice, it sounds like QuPath is doing everything right here.... copying the data as it has been told to, without manipulating it in any way.

[skalteis]

I can't claim to be fluent in Java but I had a look at the code in Bioformats and went at my TIFF files with a hex editor and I don't understand where that NUL comes from. Bioformats uses a routine to read the image name that starts at some specific offset and stops on NUL (so extracts a classic C-style zero delimited string but without the NUL). The image file has additional NULs after the terminating NUL but they should not matter if I understand the function correctly. Strange.
I also get no NUL when using bfconvert to convert from (SIS-)TIFF to OME-TIFF and open that file in QuPath.

Strange.
And I agree, it's not really QuPath's responsibility. But since NUL is illegal in Windows' clipboard anyway, one could see it as a "safeguard" for proper clipboard function, independently from the originating data source. ;-)

https://github.com/ome/bioformats/blob/d572fc0240c168cf9ca5260ddebdde55a16ff6fd/components/common/src/loci/common/RandomAccessInputStream.java#L255
https://github.com/ome/bioformats/blob/d572fc0240c168cf9ca5260ddebdde55a16ff6fd/components/common/src/loci/common/RandomAccessInputStream.java#L191
https://github.com/ome/bioformats/blob/c68f457223d9bd6be73490632774d23df7c58390/components/formats-gpl/src/loci/formats/in/SISReader.java#L174

[petebankhead]

True, but there are multiple places where text could be generated in QuPath that is copied to the clipboard. I don't really fancy trying to track down all of them...

Are you able to share a file that includes the problem? I currently have no way to replicate it.

[skalteis]

That is the file in question:
https://box.med.uni-heidelberg.de/s/qjr7vvn7P9akLMx
Password for access: QuPathrocks1!
It was created using Olympus' cell^F software and is a so-called SIS-TIFF (Olympus' own TIFF variant)

[petebankhead]

Good way to win my support with the password ;)

Ok, it took a while but I am reasonably sure it's a Bio-Formats issue. I also couldn't find a problem with the RandomAccessInputStream, but it turns out that this isn't the code that's being called; rather it calls instead
https://github.com/ome/ome-common-java/blob/94fe420a95f7859839e09e84185bc31107ba0b72/src/main/java/loci/common/RandomAccessInputStream.java#L590

I didn't trace through the (rather more complicated) logic but I can confirm with a debugger that this consistently returns a NULL at the end of the image name with the SISReader... including for other SIS files that I found posted on image.sc.

Taking QuPath (mostly) out of the equation, this script demonstrates that the null occurs:

import loci.formats.MetadataTools

def path = "/path/to/image.tif"

def reader = new loci.formats.ImageReader()
reader.setMetadataStore(MetadataTools.createOMEXMLMetadata())
reader.setId(path)

def name = reader.getMetadataStore().getImageName(0)
println "Name: ${name} (length = ${name?.length()})"
if (name && name[-1] == (char)0)
    println 'NULL found to terminate string'

With that in mind, I think it may be worth reporting to the Bio-Formats team to see if they consider this to be wrong or not.

On the QuPath side, it could check for NULL at the point when the image name is requested from Bio-Formats. I feel like this would remove any weirdness at its source. It might be possible to smuggle a NULL into the results table some other way, but I don't see an obvious path to achieving that... so I don't think the copy-to-clipboard thing should be changed.

[petebankhead]

I've just made a pull request above that should strip off any null characters at the end of image names provided by Bio-Formats. This may not fix existing projects (since the image names have already been set) but hopefully is enough to prevent it occurring in new projects.

If you've a chance to check it please let me know how it goes. I was in the process of setting up the v0.2.2 release when this issue emerged; if it looks basically ok then the proposed fix could be included in the release tomorrow.

[skalteis]

Hi,
I just quickly built your branch on Linux and can see no NUL in the image name anymore. Unfortunately I am a bit busy and can't build on Windows right now - but my SIS-TIFF files need further fixes that will (hopefully) show up in the next Bioformats tag version anyway so this should probably not delay the QuPath release today. 👍

(FYI: The pixel calibration is completely off for SIS-TIFFs but this should be fixed in Bioformats HEAD and will likely show up in the next release - ome/bioformats#3535)