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

Imspector MSR: NumberFormatException when parsing timepoints #4139

Open
dgault opened this issue Jan 10, 2024 · 4 comments
Open

Imspector MSR: NumberFormatException when parsing timepoints #4139

dgault opened this issue Jan 10, 2024 · 4 comments

Comments

@dgault
Copy link
Member

dgault commented Jan 10, 2024

This issue was raised on Imagesc thread https://forum.image.sc/t/msr-files-in-bio-formats/90582 and a sample file was provided at https://zenodo.org/records/10476252?token=eyJhbGciOiJIUzUxMiJ9.eyJpZCI6IjQ1ODRiNjkwLWExNTUtNGJlZS1hYjJhLTNjOTgzZWRiNmUwZCIsImRhdGEiOnt9LCJyYW5kb20iOiJhZjI1M2JjZDc4Y2Q5ZjE0MzhiMTZhOWQwMWRkYWQ2ZiJ9.Xz8eb6cxS-jWu5GvAnYEqkKlFzjLNoYYc3bI3mjtci7tinEdRZIvj8CjTyHqTNJj1waBVpaNJZvK8IvN0y3Y0g

Using the provided sample file the issue can be reproduced with Bio-Formats 7.1.0

The stack trace for the exception is as below:

java.lang.NumberFormatException: For input string: "2.8E-43"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:580)
	at java.lang.Integer.parseInt(Integer.java:615)
	at loci.formats.in.ImspectorReader.initFile(ImspectorReader.java:429)
	at loci.formats.FormatReader.setId(FormatReader.java:1480)
@imagesc-bot
Copy link

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/msr-files-in-bio-formats/90582/6

@scuniff
Copy link

scuniff commented Mar 8, 2024

I was able to re-produce the issue with the test image in Fiji.

In Eclipse, I modified the code in https://github.com/ome/bioformats/blob/develop/components/formats-gpl/src/loci/formats/in/ImspectorReader.java

The changes are below.

The variable valueType was 9 during the error so I moved the case 9 statement down to the section that does readInt().
It was doing readFloat() which I think causes the Exception later at line 429 as noted in stack trace in original message.

Line 316:

      switch (valueType) {
         case 10:
         case 11:
         case 12:
             key = value;
             value = String.valueOf(in.readInt() == 1);
             break;         case 2:
         case 3:          
//       case 9:                                    // moved to section below that does readInt() 
         case 13:
         case 14:
         case 17:
             key = value;
             value = String.valueOf(in.readFloat());
             break;
         case 0:
         case 1:
         case 4:
         case 5:
         case 6:
         case 8:
         case 9:                   // added case 9
            key = value;
           value = String.valueOf(in.readInt());
           break;

With the code change the error did go away and I got the Image below.

image

Not sure if this image is correct

Not sure if this is the right fix.

Not sure what else this might break.

Just thought I'd share this info. :)

@scuniff
Copy link

scuniff commented Mar 11, 2024

Referring to the original code, "Time Time Resolution" is the value of variable key when the exception occurs at line 429. The exception occurs because it is doing a readInt() but was parsed using readFloat() at line 330. Note the string "2.8E-43" in the stack trace exception.

In Eclipse I made some changes to only have the logic changed for when variable valueType is 9 and key is “Time Time Resolution”.

Starting back from the original version of ImpsectorReader.java, I just added an if statement to do readInt() when key is “Time Time Resolution” for case 9.

      case 2:
      case 3:                 
      case 9:                   
      case 13:
      case 14:
      case 17:
        key = value;
        if (key.equals("Time Time Resolution")) {
            value = String.valueOf(in.readInt());            	
        }
	// This does original logic
        else {
        value = String.valueOf(in.readFloat());
        }
        break;

The results are the same as before.

No exception
Image looks the same as above.

@dgault
Copy link
Member Author

dgault commented Mar 12, 2024

Thanks @scuniff for the testing, if you are happy that solution is working then do you want to open it as a PR and we can test it against our repository of sample files?

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

No branches or pull requests

3 participants