DESI tif cannot be open

[satarsa]

Hello
I am trying to open a tif create at the DESI synchroton using this lib, but it complains about an unknown photometric interpretation, though libtiff opens those files fine.
An example tif can be downloaded from here: https://git.3lp.cx/packages/LaB6_660c_0p8cap_SDD500_0abs_15s-00758.tif.tar.bz2
Thank you!

[fintelia]

I believe that error should only happen if you call Decoder::colortype and you should still be able to call the other methods on the decoder?

The problem is that the colortype method can only describe some sorts of photometric interpretations and returns errors for the rest. Admittedly this isn't the most helpful design...

[sophie-h]

The example image seems to show nothing for me in Eye of GNOME (libtiff) and GIMP

[fintelia]

Looking at the file, I think it may be entirely missing the PhotometricInterpretation tag, which is required by the TIFF spec. Without any indication of what the samples mean, there's no way for an image viewer to know how to properly display it.

That sort of thing doesn't matter as much for scientific data (which this image seems to be) that isn't meant to directly be displayed. I am able to view the contents in QGIS so the rest of the file contents do seem to be intact

[satarsa]

The example image seems to show nothing for me in Eye of GNOME (libtiff) and GIMP

The is diffraction data from a synchrotron instrument, it still contains some image which can be displayed (typical multi crystal diffraction pattern, if you are still interested, you may use this software: https://soft.snbl.eu/snbltb/snbltb.html, the tool Fiewer), but the image itself is useless, the main part is the number of photons counted by each pixel.

[satarsa]

Looking at the file, I think it may be entirely missing the PhotometricInterpretation tag, which is required by the TIFF spec. Without any indication of what the samples mean, there's no way for an image viewer to know how to properly display it.

I understand that, but we have to live in the real world. I was given these data to convert it to more reasonable format and process it using some crystallography tools. Personally, I detest using tiff as container for crystallography data, there are better formats optimized for those purposes, but people are people, they store tiffs and we have to live with this.

That sort of thing doesn't matter as much for scientific data (which this image seems to be) that isn't meant to directly be displayed. I am able to view the contents in QGIS so the rest of the file contents do seem to be intact

As I mentioned in the previous comment you can still display it, though it is a bit useless. I maintain two libraries to read different crystallographic format files, one of them is in C++ https://git.3lp.cx/dyadkin/cryio, and one in Rust https://git.3lp.cx/dyadkin/cryiorust. In the end, the C++ one uses libtiff and it opens files fine, but the Rust version panics due to the missing PhotometricInterpretation. My idea was that may be the Rust tiff should be as tolerant as libtiff.

[berke]

Hello, I ran into the same issue. I have a bunch of single-band U16 TIFF files that do not have the photometric interpretation tag. I can open the files using other tools, but I get the error about the unknown photometric interpretation if I use this tiff crate via image. As a quick hack, I changed image.rs like this to give a default value for that tag:

        let photometric_interpretation = tag_reader
            .find_tag(Tag::PhotometricInterpretation)?
            .map(Value::into_u16)
            .transpose()?
            .and_then(PhotometricInterpretation::from_u16)
	    .unwrap_or(PhotometricInterpretation::BlackIsZero);
            // .ok_or(TiffUnsupportedError::UnknownInterpretation)?;

This works in my case, but in general it may not, it may also silently induce people into error. Not sure what the best thing to do would be. Looking at what other TIFF libraries do might be helpful.

[fintelia]

Sounds like we should probably store an Option<PhotometricInterpretation> and only return an error for the methods that actually need to know what the photometric interpretation is (which might just be Decoder::colortype?)