Honor force_sktiff in ome_to_binary - #1262
Open
adityasingh2400 wants to merge 1 commit into
Open
Conversation
ome_to_binary computed use_sktiff as `not HAS_SCANIMAGE`, ignoring the force_sktiff option that tiff_to_binary already honors. The variable was also dead for reader selection: every open site re-derived the choice from HAS_SCANIMAGE inline, so setting force_sktiff had no effect on OME-TIFF imports at all. Derive use_sktiff from force_sktiff the same way tiff_to_binary does, and route every reader selection in the function through it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1250.
ome_to_binarycomputeduse_sktiff = not HAS_SCANIMAGE, ignoring theforce_sktiffoption that the siblingtiff_to_binaryalready honors one function up.The variable was also dead for the purpose of picking a reader. Every open site re-derived the choice from
HAS_SCANIMAGEinline instead of consultinguse_sktiff: theTiffReaderalias, the page count probe, both single page reads, and bothopen_tiffcalls.use_sktiffwas only ever passed on toread_tiff. So even fixing the one assignment would not have changed which reader opened the file, and settingforce_sktiffhad no effect on OME-TIFF imports at all.This derives
use_sktiffthe waytiff_to_binarydoes and routes every reader selection in the function through it. Withforce_sktifffalse the behaviour is bit identical, sinceuse_sktiffandnot HAS_SCANIMAGEagree in that case.Two tests in
tests/test_io.py. They generate their own small OME-style TIFFs withtifffileand monkeypatchHAS_SCANIMAGEandScanImageTiffReader, so they need neither the cached input download norScanImageTiffReaderto be installed. One assertsforce_sktiff=Truereaches tifffile and writes the expected binary, the other asserts the default path still prefers ScanImageTiffReader when it is available, which guards the change in the other direction.Reverting
suite2p/io/tiff.pyfrom main makes the first fail withRuntimeError: ScanImageTiffReader was used. Both pass after.Disclosure: this change was prepared with AI assistance. I have reviewed and tested it.