Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incompatible Float64 encoding? #84

Closed
johnnychen94 opened this issue Jul 27, 2022 · 6 comments
Closed

incompatible Float64 encoding? #84

johnnychen94 opened this issue Jul 27, 2022 · 6 comments

Comments

@johnnychen94
Copy link
Contributor

This is only an issue of Float64 and not N0f8.

using ImageCore, TiffImages
img = rand(RGB{Float64}, 64, 64)
TiffImages.save("tmp.tif", img)
img_loadback = TiffImages.load("tmp.tif")

img == img_loadback # true

However, this "tmp.tif" file is not loadable by other image viewers (both macOS and Windows' default image viewer fail to open it).

image

@tlnagy
Copy link
Owner

tlnagy commented Jul 27, 2022

Can those default image viewers open 64bit floating bit RGBs normally? AFAIK, support for opening those is pretty limited to scientific TIFF readers, i.e. Fiji/ImageJ or Napari.

For example Fiji is capable of opening them with the BioFormats plugin:

image

And Napari as well:

image

@johnnychen94
Copy link
Contributor Author

I see. So this is because our TiffImages format is too advanced?

@tlnagy
Copy link
Owner

tlnagy commented Jul 28, 2022

Yeah, unfortunately simple TIFF readers are quite limited in what datatypes they support. TiffImages.jl supports reading/writing many combinations that are valid TIFFs but other less flexible readers might not support.

That said, I don't support all TIFFs either, but I try to support most common scientific TIFF types.

E.g. some readers only support Gray{Float32} and not Gray{Float64} etc while both are valid according to the spec.

@johnnychen94
Copy link
Contributor Author

johnnychen94 commented Jul 28, 2022

Curiously, if we wrap the LibTIFF C library, would you like to maintain it as a fallback backend inside TiffImages for cases we don't have much time/priority to implement?

The benefit of keeping it inside TiffImages instead of FileIO is that we can hide the inconsistency by designing the backend delegation policy. Another alternative is to have meta TIffIO package to smartly call either LibTIFF.jl and TiffImages.jl on demand.

@tlnagy
Copy link
Owner

tlnagy commented Jul 28, 2022

I simply don't have the bandwidth to wrap it or really maintain this year. This package serves my needs for processing my microscopy images (particularly with it's advanced mmapping facilities that LibTIFF doesn't have AFAIK).

I haven't gotten too many complaints since ImageIO.jl switched to using TiffImages.jl. Has it been causing problems for you?

@johnnychen94
Copy link
Contributor Author

johnnychen94 commented Jul 28, 2022

Yeap totally understandable.

Has it been causing problems for you?

Not much for the main functionality. The Jpeg compression stuff comes from the recent GSoC project JuliaImages/ExifViewer.jl#5 where thumbnail is a TIFF bytes sequence with JPEG compression.

FYI, I'm working part-time in tongyuan.cc to bring a compatible image processing toolbox to MATLAB and I sometimes find compatibility issues across implementations for edge cases and advanced keyword options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants