[MINC-users] Time frame start values

[Robert D. Vincent]

Hi Alex,

I may have solved some of these issues - I just pushed a few small updates
to github.

With at least some of the PET data I have, using the Acquisition time field
is useful for the PET timings, although it produces a non-zero start value
in most cases.

Also I found and fixed a bug where we incorporated Siemens proprietary
information into the PET DICOM, but our Siemens-specific code is only
correct when used with MR data.

Please try these out and let me know if you're still having problems.

    -bert

On Fri, Mar 29, 2019 at 4:39 PM Jean-Philippe Coutu <jp at biospective.com>
wrote:

> 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>