ScanR: clear the pixel buffer when an invalid TIFF is found

[melissalinkert]

This prevents openBytes from returning garbage data when the real pixel data is missing.

/cc @chris-allan

[ghost]

This looks OK in terms of clearing the buffer. However, I do wonder why the FormatException isn't being propagated to the caller here, rather than being suppressed, which would directly inform the caller that there had been a failure. Instead, they are just returned a buffer, with no way to determine if there was a problem. I.e. even with the patch the pixel data being returned is still invalid, it's just not random.

[melissalinkert]

FormatException is caught to be consistent with other readers and most other imaging software - returning a blank plane if one file is invalid or missing is pretty standard. That exception being thrown in openBytes invariably means that there is something wrong with the TIFF being opened; there really isn't anything that the caller can do about that, and it's generally more useful to be able to read all of the other planes and metadata. The caller can still know that something is off by the fact that the plane is completely black.

Arguably we could do a better job of logging that sort of problem, but there are multiple readers that do the same thing, so I think that would be for a separate PR.

[ghost]

The scanr commit tests all pass. No problems with this being merged.

With respect to the exception stuff, I'd argue that it's really the responsibility of the caller to decide what to do on error, rather than hardcoding the policy in openBytes. There's no way to tell the difference between a real blank plane and a blank plane as a result of an error. This patch doesn't alter that behaviour at all though; that's just incidental.

[chris-allan]

Just adding that I have tested a problem dataset and the change here works as expected with a blank, full of zeros plane.