[MINC-users] Time frame start values

[Jean-Philippe Coutu]

Hi Robert,

I like your idea of using the frame widths, and I just wanted to mention
one caveat we stumbled upon recently, where this might not work. We have
had to convert a dataset where the time frames were not contiguous, and
therefore there were effectively missing time frames. I think this is
unusual and maybe dcm2mnc should not be expected to be able to convert
that, but I just thought I would mention it. I think having this option you
suggest would definitely be good for this case though.

We have been fixing up 4D cases for a while now, which largely seem to have
issues in get_file_indices(), mostly because of what you stated: unusual
worthlessness of certain dicom fields for certain situations/scanners.
Basically there is no ideal order of prioritisation for which dicom tags
are always more reliable than other when it comes to finding time indices
(and also all sorts of range-checking issues). We haven't made pull
requests for those changes yet because I think we need to reorganise them a
bit better.

Best,
JP

On Thu, Mar 28, 2019 at 9:42 AM Robert D. Vincent <bert at phalarope.com>
wrote:

> Hi Alex,
>
> I've heard of these issues in a number of instances, I am (slowly, when
> time permits) trying to resolve one particular case in dcm2mnc.
>
> PET files often use the DICOM field 0054:1300, the "Frame Reference Time",
> as the main (or only) indication of PET frame start times. However, as you
> can see at the link I have provided, the exact meaning of this field is
> undefined, so it is unusually worthless even for DICOM. Some PET sequences
> use other fields to indicate the frame times, but consistency here is poor.
>
> https://www.dabsoft.ch/dicom/3/C.8.9.4.1.5/
>
> My intended solution is to use the frame widths ("Actual Frame Duration",
> 0018:1242) to reconstruct the MINC dimension by simply setting the start
> time of each frame to the sum of the preceding frame widths. This relies on
> the accuracy of these frame widths, but in my experience this may be more
> reliable than relying on the frame times. However, if the frame times are
> somehow meaningful, that information will be lost (or at least not stored
> in a standard place). So my plan is to make this depend on a command line
> option.
>
>     -bert
>
> On Thu, Mar 28, 2019 at 9:15 AM Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
>
> > Hello all,
> >
> > I've running into an issue I don't know what to do with (yet). How are
> (or
> > should) start values be interpreted in a MINC time-dimension?
> >
> > For spatial dimensions, the voxel positions are in the center of the
> voxel;
> > but in converting dynamic PET data from various scanners, we are seeing
> > what looks like variations between scanners in terms of whether the start
> > is center-frame, or start-of-frame.
> >
> > We also sometimes end up with negative time steps out of dcm2mnc, which
> > calls into question whether (a) that should ever happen; and (b) how for
> > example mincreshape behaves when re-ordering that dimension. My
> assumption
> > is that mincreshape will interpret the start to be center-frame, and that
> > therefore changing the sign of the time-step might end up with a wrong
> > start value.
> >
> > If anybody has thoughts about or experience with these issues, please
> share
> > :-)
> >
> > Thanks,
> >
> > -- A
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>