[ecatpet2bids] Specify starting frame when header and dataframe size mismatch

[noahg-neuroimage]

I'm having trouble using ecatpet2bids as the ecat files I'm using have a mismatch between the number of frames in the header and the number of frames in the image dataframe. The scanner I'm using produces images with an empty frame at the beginning of the scan, which is later removed, so for an image with N frames, the header thinks there are N+1 frames. This triggers an error (pypet2bids/ecat2nii.py, line 100), which seems to be the intended functionality, but I'd like to be able to specify how many or which frames I'd like to convert to the nifti file.

[bendhouseart]

@noahg-neuroimage okay, so I know you described exactly what I just observed from the data you were able to share with me....but I guess I had to see it.

You mentioned at some point that this was legacy data? If my recollection is correct, I'm really hoping you could help locate the accompanying paper.

...I don't, understand why they would lop off the first sub-header, but not update the frame number as well.

[bendhouseart]

I think you're going to end up making me fix ecat write so that you're able to clean up the main header of this data...

[bendhouseart]

Okay, I went ahead and updated the headers to reflect the actual number of frames and sent them back to you as *_fixed.v, the output nifti's produced by ecatpet2bids *_fixed.v --nifti --convert are included as well.

The output nifiti's looked alright under FreeView, but I've sent them back to you for inspection. I think the best way to move forward on this is to wrap up what I did into a little command line utility and add it into pet2bids. Then you should be able to correct any future ECAT's you come across with this issue.

Let me know what you think @noahg-neuroimage

[noahg-neuroimage]

I took a look- the OSEM image seems to have performed well, but I have two concerns, which are somewhat related.

First, looking at the two images you returned- fbp_fixed and osem_fixed- I noticed the values are exactly the same. Sure enough, in fbp_fixed.json the field 'ReconMethodName' takes on value 'osem-wa4/16' when this should be Filtered Backprojection. Double checking the original FBP file I sent it seems to indeed be the FBP reconstruction rather than a file name mixup.

I bring this up because I've noticed different conversion tools seem to handle scale factors poorly, and it's especially apparent in the filtered backprojection reconstructions. When I use the tool that is treated as more 'standard' in my group, we get counts on order 10^4/5 min/voxel at the brightest spots as an example for the image I sent, but in the version I got back these values were scaled to ~10^11. Perhaps this is just a unit conversion, which we can correct for later, but I've noticed other conversion software I've attempted to use in the past that make this change also end up corrupting the values in FBP reconstructions.

To begin with, can you confirm that the modified ecatpet2bids behaves with the original fbp.v file I sent? From there we can work out how to approach this scaling issue.

[bendhouseart]

First, looking at the two images you returned- fbp_fixed and osem_fixed- I noticed the values are exactly the same. Sure enough, in fbp_fixed.json the field 'ReconMethodName' takes on value 'osem-wa4/16' when this should be Filtered Backprojection. Double checking the original FBP file I sent it seems to indeed be the FBP reconstruction rather than a file name mixup.

That error occurred between pet2bids and the keyboard; the correct images are in the mail.

When I use the tool that is treated as more 'standard' in my group, we get counts on order 10^4/5 min/voxel at the brightest spots as an example for the image I sent, but in the version I got back these values were scaled to ~10^11.

We've really only had live ecat data from a single site to work with, so it's very possible that it only happens to work really well there. You've made me very curious about what's going on now with ecat scaling as you've brought it up both here and in a PR you posted previously. However, we're getting off topic in this issue.

If you're able to touch up mismatching main header values with a single command e.g. modifyecat ecatfile.v --mainheader FRAME_NUMBER=71 would that solve this issue for you?

If yes, I can make a PR implementing the code I used to update the ecats I sent to you this evening.

[noahg-neuroimage]

I've received the new version, and it does seem to solve the issue here: once the FRAME_NUMBER variable in the header is changed, it should be sufficient to run ecatpet2bids. Thanks for your work to assist me in this; we can continue the conversation on scaling in the other PR.

[bendhouseart]

Great, added script to #270, usage is as follows:

ecatheaderupdate <ecat file> NUM_FRAMES=71

Or

python pypet2bids/ecat_header_update.py <ecat file> NUM_FRAMES=71

It only does the main header for now...

I'll probably hold off on merging this until Monday so that I don't end up pushing bugs to PyPi with the new minor version. If you absolutely need it before then, please just ping me here and I'll try to integrate it sooner.

Otherwise have a great weekend!

[CPernet]

can we close this one? @bendhouseart