Hi David, I took a look at the BART source code yesterday. It’s in C, so that would work. It’s even packaged in Debian, which would ease things on Linux, although it appeared only to include a few of the commands in BART.
By the way, while you’re about: could you complete the transfer of PDL::Graphics::Prima by also transferring Prima::Plot, PDL::Graphics::Prima::DataSet::Annotation, etc? See https://pause.perl.org/pause/authenquery?ACTION=peek_perms&pause99_peek_perms_by=me&pause99_peek_perms_query=Prima%3A%3APlot&pause99_peek_perms_sub=Submit which shows it’s still owned by you. Best regards, Ed ________________________________ From: David Mertens <dcmertens.p...@gmail.com> Sent: Wednesday, May 15, 2024 9:50:03 PM To: Ingo Schmid <ingo...@gmx.at> Cc: perldl <pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL and bart Regarding "using both in an optimal way": Have you considered extracting the source code for the useful algorithms and writing PDL::PP wrappers for them? I assume they are written in C, though if they are not this would be a silly idea. Otherwise I guess you could write Perl scripts that shell out to bart for its useful calculations. You should be able to use fastraw or flexraw for the memory mapping, then read/write your own bart-compatible header files. When in doubt, I've just dug into the sources for Fastraw to understand how it works, and that's probably the fastest way to leverage it. The internals are really quite simple. My suggestion for finding the best flow is to create a Perl-side layer of abstraction. Write your own module with functions whose purpose is to perform bart calculations. Initially, write it to leverage Bart exclusively using temp files. Probably you would have to create objects that basically just contain the temp filename. Pay attention to the points of friction and only re-implement in PDL when it is either super easy or significantly reduces that friction. The PDL-based calculations would return an object that is in a PDL sub-class of the original which, if fed into a pure-bart method, would know how to create a temp-file version of itself. Is that helpful? David On Wed, May 15, 2024, 9:05 AM Ingo Schmid via pdl-general <pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net>> wrote: 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 pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/pdl-general
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
