multi-frame frame rate slower than expected

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
merlin
Posts: 41
Joined: Tue, 2008-03-04, 16:21

multi-frame frame rate slower than expected

#1 Post by merlin »

Hi,

I have created a multi-frame DICOM file with DCM_NumberOfFrames set to 150 frames and DCM_FrameTime set to 20 milliseconds.

I would expect to see a playback at 50 FPS which is about 3 second in length. However, when viewing my multi-frame file with a DICOM viewer (I tried several), the frame rate is much slower (about half what I expect it to be).

Am I missing something?

Thank you,
merlin

alwittta
Posts: 111
Joined: Wed, 2006-03-15, 08:30

#2 Post by alwittta »

Hi Merlin,

The information you provided here is insufficient to understand the problem. Can you provide some more information like;
DCM_Rows
DCM_Columns
DCM_SamplesPerPixel
DCM_PhotometricInterpretation
DCM_BitsAllocated
DCM_BitsStored
DCM_HighBit
DCM_TransferSyntaxUID

merlin
Posts: 41
Joined: Tue, 2008-03-04, 16:21

#3 Post by merlin »

Hi
Here is the information you requested:

DCM_Rows: 343
DCM_Columns: 374
DCM_SamplesPerPixel: 1
DCM_PhotometricInterpretation: MONOCHROME2
DCM_BitsAllocated: 8
DCM_BitsStored: 8
DCM_HighBit: 7
DCM_TransferSyntaxUID: 1.2.840.10008.1.2.1

Thank you.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1461
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#4 Post by Marco Eichelberg »

The viewer might simply be too slow. As far as I know, frame rates of 50 FPS are rather unusual in medical imaging, where you typically see 12.5 or 25 FPS.

st80rules
Posts: 190
Joined: Tue, 2007-05-08, 17:45

#5 Post by st80rules »

Really? I didn't know that. Our viewer has 60 fps in 3D mode, and even at full features (lighting, full LOD, etc) it only drops to about 30. Are you talking about commercial viewers?

tclune
Posts: 19
Joined: Wed, 2008-03-26, 15:57

Re: multi-frame frame rate slower than expected

#6 Post by tclune »

merlin wrote:Hi,

I have created a multi-frame DICOM file with DCM_NumberOfFrames set to 150 frames and DCM_FrameTime set to 20 milliseconds.

I would expect to see a playback at 50 FPS which is about 3 second in length. However, when viewing my multi-frame file with a DICOM viewer (I tried several), the frame rate is much slower (about half what I expect it to be).

Am I missing something?

Thank you,
merlin
If you are using a free viewer, it may simply not be paying any attention at all to the frametime attribute. We evaluated about a half-dozen free viewers, and none of the ones that we tried honored the loop times we specified. Most commonly, they have a choice that lets the user make the loops run slower or faster, but never at the actual time the frames were acquired! We have since adopted a commercial viewer, NetShowcase, which does the right thing with loops. Actually, we have since discovered that a few of the "big boys" have opted for the same commercial viewer. You can get a license for installing it on CDs that you burn as the default viewer. FWIW.

--Tom Clune
Last edited by tclune on Wed, 2011-02-16, 12:46, edited 3 times in total.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1461
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#7 Post by Marco Eichelberg »

Are you talking about commercial viewers?
No, I was not referring to any specific viewer. It is just that most modalities (as far as I am aware of) produce multiframe objects with frame rates of 12.5 or 25 fps, and anything that is legal but unusual in DICOM has good chances of not being fully supported by some viewers - there are just too many implementations that only do the right thing for "usual" images (presumably those the developers had available for testing) but do not implement the full spec.

tclune
Posts: 19
Joined: Wed, 2008-03-26, 15:57

#8 Post by tclune »

It is just that most modalities (as far as I am aware of) produce multiframe objects with frame rates of 12.5 or 25 fps...
Just a quick FYI -- ultrasound loops run at a variety of speeds. I know of no ultrasound that is limited to either of these acquisition speeds, and normally the playback rate is real-time. Sometimes that's not practical -- some cardio acquisitions are 100 fps or more, for example. But normally, the acquisition rate is determined by the speed of sound in the body, and varies with depth of scan and line density of imaging. Typical rates would be in the range of 20-50 fps. It is not uncommon for archived loops to be decimated for storage considerations, but that varies with manufacturer and user policy. FWIW

--Tom Clune
Last edited by tclune on Wed, 2011-02-16, 12:46, edited 2 times in total.

changtikavita
Posts: 3
Joined: Thu, 2009-03-12, 10:33

Re: multi-frame frame rate slower than expected

#9 Post by changtikavita »

Hi,
please can I get some sample code how you created the multiframe dicom file.
I am trying this, but I am not getting..
I am want to create a dicom multiframe file from avi file. I will be getting buffer and bitmap info header.

Please help me.

Thanks in advance.

tclune
Posts: 19
Joined: Wed, 2008-03-26, 15:57

Re: multi-frame frame rate slower than expected

#10 Post by tclune »

changtikavita wrote:Hi,
please can I get some sample code how you created the multiframe dicom file.
I am trying this, but I am not getting..
I am want to create a dicom multiframe file from avi file. I will be getting buffer and bitmap info header.
Sorry to be so slow in responding. I have been away on vacation. It is a relatively large question how to encode multi-frame images. The most important thing is to get clear on the idea of using fragments (and remember that the first fragment is the fragment for the indices into the other fragments). While a fragment is not necessarily the same thing as a frame, it usually is and makes everything pretty simple to encode. Consult 3.5 Annex A for relatively detailed information. Also, you need to set the number of frames attribute if that number is greater than 1. If the timing is important in your app, you need to set the frame increment pointer and frame time vector values (if I'm not mistaken, you can use a different way of inidcating the frame times than this, but that's the way we do it).

As to code fragment, I doubt that it would help. I rewrote an earlier snapshot version of the library to support operating frame-by-frame instead of the whole image at a time, because we were running out of virtual address space with even relatively short loops using the library as it existed. My rewrite is specific to our app, and Marco has pointed out some logical errors that I made for general-purpose usage. So I would just be leading you into the holes in my own understanding if I shared that code!

Hope this helps.

--Tom Clune

Post Reply

Who is online

Users browsing this forum: Baidu [Spider], Bing [Bot] and 0 guests