Does anyone happen to know what the LCModel/gelx/bin2raw program does exactly?
Our local GE MRI was recently updated to software revision 30.0, and our licensed version of LCModel using lcmgui now throws an error when trying to load the new Pfiles. If I understand how lcmgui works, it first calls the gelx/bin2raw preprocessor program that combines channels, transients and maybe a basic phase/freq correction before saving the data as a raw file and calling the lcmodel fitting tool with a basis set and control file. The project we’re collecting these Pfiles for has been ongoing for years and we have a large database of LCmodel results. I would like to replicate this bin2raw program with an open source program so we can continue to use the open sourced lcmodel fitting tool.
LCModel is not being actively developed anymore and the source code of the helper programs (lcmgui, bin2raw, makebasis etc) was never published, so changes to headers in the proprietary formats will not be supported any longer. Your best bet is to switch your workflow to one of the newer open-source processing tools (Osprey, FSL-MRS, spant, etc.) that can read GE files of any generation and write LCModel raw files. Osprey allows you to call LCModel directly from within (optionally), I believe that the other tools might have that functionality too.
Thanks for the fast reply Georg. I probably wasn’t as clear as I should have been.
I do realize that only the source code for the main LCModel fitting tool was released and not the helper programs. In fact, I’ve downloaded, compiled, and successfully run the lcmodel on my MacBook, generating my own control file and using either python (via suspect) or simplified FID-A to create .raw files with simple channel/transient averaging, then using the same LCmodel basis set as original full-licensed LCmodel. But so far, my results from manual lcmodel fitting are noticeably different that fully licensed LCmodel.
I do fully intend to migrate to using more modern open-source tools and am actively developing a pipeline with FSL-MRS. However, all of these modern programs do much more modern (& better) corrections prior to fitting and therefore the results are not comparable to our older datasets processed with LCmodel using the gelx/bin2raw. My plan is to: 1) reproduce exactly what bin2raw program does (hopefully) so that I can continue to generate the exact same results as original LCmodel that worked for GE Pfiles up to rev29.1, and then 2) process all our data through FSL-MRS with modern corrections, and 3) compare the results between the two workflows across all >15years of our data. This will allow myself and colleagues an opportunity to better understand the impact of modern corrections, and to determine/understand quality issues.
That’s interesting. Have you looked over the thread here?
There are a number of compiler optimisations which may lead to very slight deviations in some of the floating point operations, which could potentially accumulate to more substantial deviations – so perhaps that’s something to look into. Also I’m curious whether this was an M1/M2 macbook or an Intel system?
Regarding GE compatibility in future releases (beyond rev 30) – at some stage, we’ll likely need to move over to the ScanArchive format. I believe there may already be some work in this direction (@wclarke, @noeskera).
Unfortunately being closed source it’s impossible to be certain exactly what bin2raw does, but I would say your understanding is basically correct – except, surprisingly, it doesn’t appear to be combining channels. What we usually see coming out (for single-voxel) is a single FID for each coil element, with differing phases. So it’s combining transients for each receiver separately, and apparently not doing much with the phase across elements (although perhaps within). It’s also not doing ECC: water reference is maintained explicitly for this purpose; it happens by default (but optionally) in the main lcmodel program.
Note that some of the combination (eg, adding transients across each full phase cycle) may happen on the scanner already, especially for standard PRESS sequences, if you haven’t explicitly asked the sequence not to do that.
There has been quite a lot of work towards improved spectral registration and automatic filtering of bad averages in recent years – I think it’s fair to assume that bin2raw has not been updated to take into account recent developments in that area. Robust spectral registration with modern methods implemented in FID-A/Gannet/FSL-MRS/Osprey or whatever other up-to-date tool you prefer will likely outperform these – at least for healthy brain tissue. For lesion and non-brain, this is not necessarily the case without further tuning.
My understanding is that the ScanArchive format will continue to be a closed-source/proprietary format only readable in GE’s Orchestra software, and the ability to load such a file in open-source/third-party propriety software will not be possible.
That’s possible – in which case conversion on the scanner (using the Orchestra libraries) may also be a way forward. Fortunately we haven’t needed to deal with this, yet.