Hi Ingo, My best answer to your direct question is a non-answer: only you know what is your easiest workflow. However, if bart does everything via new files for each stage, and you feel (as sounds likely from your description) that the various transformations can be done quicker but still correctly using PDL slicing stuff (especially as, with vaffine transformations like slice and mv, a copy is not made of the data), then you should run with that. Probably you’d want to have PDL write out to a file for stuff that bart is best at. I would note that one of your example bart commands is “nufft”, and PDL has several FFT implementations available that might be useful to compare that to (Slatec, FFTW3, the provided PDL::FFT).
PDL::IO::FlexRaw is probably fine for memory-mapping stuff, though I’ve not really used it. I have dabbled with PDL::IO::FastRaw to help with Photonic, and that works fine for stuff that’s too big for RAM. If you find any problems with FlexRaw, please report them here so they can be fixed. Once you have stuff working, I hope you’ll put it on CPAN! Best regards, Ed ________________________________ From: Ingo Schmid via pdl-general <[email protected]> Sent: Wednesday, May 15, 2024 2:04:41 PM To: perldl <[email protected]> Subject: [Pdl-general] PDL and bart Hi, I both use PDL and recently started using bart (https://mrirecon.github.io/bart/). Documentation is somewhere between non-existent and horribly insufficient, before you ask. It has implementations of MRI reconstruction algorithms and its file format is complex float, very very similar to the FlexRaw format. They come in pairs of binary data cfl and text hdr files. Here's a sample dump, of which only the #Dimensions lines are essential: # Dimensions 200 200 200 1 1 1 1 1 1 1 1 1 1 1 1 1 # Command pics -d 5 -R W:7:0:0.0015 -e -i 100 -S -t traj549 reshData549 sens reco_l1 # Files >reco_l1 <sens <reshData549 <traj549 # Creator BART v0.8.00-196-g5947a32 I intend to wrap readflex/writeflex calls into readcfl/writecfl (there are matlab and python interfaces). Every command reads one or more files and the result is stored in a new one. This, of course, is not always efficient if things are temporary and fit into memory. The good thing is, you can run these from any shell/command prompt. For example > bart transpose 1 11 _tmp _tmp1 reads _tmp, swaps dimensions 1 and 11 (starts at 0) and writes _tmp1 or > bart slice 1 $c1 $eof _eof_c1; creates a slice at position $c1 in dimension 1 and writes that to _eof_c1. These are things done much more efficiently in PDL, for example. Others are very useful (nufft, nlinv), though specific to the field (pics, cc). Now, here comes my question. Do you see a straight-forward workflow to use both bart and PDL in its optimal way? How to best memory map files, possibly directly into a piddle? I am grateful for your input. Best wishes Ingo
_______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
