Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to store video frames (e.g., for colonoscopy)
217 views
Skip to first unread message
greggy
Jan 12, 2012, 7:20:20 PM1/12/12
to
My current project is taking a video for a colonoscopy procedure and
storing it in a DICOM format. The device is properly identified as a
secondary capture device, and I know I could store the frames
individually in a multi-frame secondary capture object. But is that
the best format to use overall? Would a standard video file be more
appropriate? If so, what formats are typically used these days and
why?
Thoughts? Ideas? Issues? Anyone...
storing it in a DICOM format. The device is properly identified as a
secondary capture device, and I know I could store the frames
individually in a multi-frame secondary capture object. But is that
the best format to use overall? Would a standard video file be more
appropriate? If so, what formats are typically used these days and
why?
Thoughts? Ideas? Issues? Anyone...
Harry Solomon
Jan 13, 2012, 5:12:45 PM1/13/12
to
I suggest that you not use the Secondary Capture IOD, but rather the
Video Endoscopic Image IOD. And specifically for the endoscopy use
case, DICOM has adopted both MPEG2 and MPEG4 as video formats that can
be encapsulated as the pixel data. MPEG4 was championed by the
endoscopy manufacturers in Europe, so I would bet that is a good
direction to go.
- Harry Solomon
Video Endoscopic Image IOD. And specifically for the endoscopy use
case, DICOM has adopted both MPEG2 and MPEG4 as video formats that can
be encapsulated as the pixel data. MPEG4 was championed by the
endoscopy manufacturers in Europe, so I would bet that is a good
direction to go.
- Harry Solomon
MrGreen...@yahoo.com
Jan 13, 2012, 9:46:11 PM1/13/12
to
That is what I was looking for.
I was thinking that the video may be as long as 15 minutes or so,
which would result in a large file. What is the upper end of the file
size that I should watch out for in most clinical environments?
I was thinking that the video may be as long as 15 minutes or so,
which would result in a large file. What is the upper end of the file
size that I should watch out for in most clinical environments?
Harry Solomon
Jan 14, 2012, 4:58:44 PM1/14/12
to
The current generation of PACS have gnerally been validated with file
sizes of several hundred megabytes, but the practical issue is that
most DICOM applications will transfer an entire SOP Instance before
processing it, and most will want to put the entire object into
memory. With gigabit Ethernet and multi-GB RAM on workstations, you
are probably pretty safe if you limit each object to 100 MB. For
colonoscopies, I suspect you don't need more than 10-15 fps, so even
with hi-def MPEG4 that is several minutes.
On Jan 13, 8:46 pm, "gregofi...@yahoo.com" <MrGreenWithA...@yahoo.com>
wrote:
sizes of several hundred megabytes, but the practical issue is that
most DICOM applications will transfer an entire SOP Instance before
processing it, and most will want to put the entire object into
memory. With gigabit Ethernet and multi-GB RAM on workstations, you
are probably pretty safe if you limit each object to 100 MB. For
colonoscopies, I suspect you don't need more than 10-15 fps, so even
with hi-def MPEG4 that is several minutes.
On Jan 13, 8:46 pm, "gregofi...@yahoo.com" <MrGreenWithA...@yahoo.com>
wrote:
David Clunie
Jan 15, 2012, 10:32:50 AM1/15/12
to
Hi
If one is just going to store and regurgitate but not view
(e.g., you have dedicated video player that isn't in the
PACS), then your limiting factor may not be memory but
rather parsing the DICOM "header" (which is required for
database insertion); that said, not all parsers will skip
the pixel data cleanly if some limits are not observed (or
in the worst case, not skip it at all, which may result in
terrible performance).
In terms of the underlying toolkits for parsing DICOM objects,
theoretically uncompressed pixel data of (2^32)-2 (just under
4GB) can be supported, but many toolkits have problems with
the sign bit for 32 bit data, so 2^31 is a better limit (2GB)
to stick to.
Theoretically compressed pixel data can be larger, as long as
each fragment in the encapsulated pixel data bitstream observes
the above limit (set by fixed length sequence item length field).
There is also a practical limit imposed by Rows (16 bit unsigned
value), Columns (unsigned 16 bit value) and Number of Frames
(unsigned 16 bit value). Since the number of rows and columns
is fixed for a video stream, the limit of (2^16)-1 frames
(65,535) may be what constrains the maximum video stream length,
depending on how heavily it is compressed.
All that said, most PACS do not accept any of the MPEG video
transfer syntaxes (.100 and .101 MPEG2 or .102 and .103 MPEG4)
yet anyhow, though theoretically they can be configured to do
so, but you may instead need to resort to per-frame lossy JPEG,
which is much more widely supported (given its historical use
for ultrasound cine loops).
Same goes for the SOP Class; like Harry said, the Video SOP
Classes are preferable, but you may need to fall back (during
association negotiation) to the MF True Color Secondary Capture,
if the PACS is not or cannot be configured to accept the video.
Don't forget to consider the impact on the WADO and XDS-I.b
gateways serving up the PACS content, and on CD/DVD media
export and import.
Since users do not like limits, do not do what they are
told, and will want to set the level of compression based
on quality not arbitrary system limits, if I were building
this I would certainly anticipate the need to quietly fragment
a video stream of any length into chunks that would fit into
separate instances, and reassemble them (unobtrusively) when
retrieving them for display, though obviously it would be
preferable if such fragmentation were based on user actions
(like starting and stopping the recording).
David
If one is just going to store and regurgitate but not view
(e.g., you have dedicated video player that isn't in the
PACS), then your limiting factor may not be memory but
rather parsing the DICOM "header" (which is required for
database insertion); that said, not all parsers will skip
the pixel data cleanly if some limits are not observed (or
in the worst case, not skip it at all, which may result in
terrible performance).
In terms of the underlying toolkits for parsing DICOM objects,
theoretically uncompressed pixel data of (2^32)-2 (just under
4GB) can be supported, but many toolkits have problems with
the sign bit for 32 bit data, so 2^31 is a better limit (2GB)
to stick to.
Theoretically compressed pixel data can be larger, as long as
each fragment in the encapsulated pixel data bitstream observes
the above limit (set by fixed length sequence item length field).
There is also a practical limit imposed by Rows (16 bit unsigned
value), Columns (unsigned 16 bit value) and Number of Frames
(unsigned 16 bit value). Since the number of rows and columns
is fixed for a video stream, the limit of (2^16)-1 frames
(65,535) may be what constrains the maximum video stream length,
depending on how heavily it is compressed.
All that said, most PACS do not accept any of the MPEG video
transfer syntaxes (.100 and .101 MPEG2 or .102 and .103 MPEG4)
yet anyhow, though theoretically they can be configured to do
so, but you may instead need to resort to per-frame lossy JPEG,
which is much more widely supported (given its historical use
for ultrasound cine loops).
Same goes for the SOP Class; like Harry said, the Video SOP
Classes are preferable, but you may need to fall back (during
association negotiation) to the MF True Color Secondary Capture,
if the PACS is not or cannot be configured to accept the video.
Don't forget to consider the impact on the WADO and XDS-I.b
gateways serving up the PACS content, and on CD/DVD media
export and import.
Since users do not like limits, do not do what they are
told, and will want to set the level of compression based
on quality not arbitrary system limits, if I were building
this I would certainly anticipate the need to quietly fragment
a video stream of any length into chunks that would fit into
separate instances, and reassemble them (unobtrusively) when
retrieving them for display, though obviously it would be
preferable if such fragmentation were based on user actions
(like starting and stopping the recording).
David
David Clunie
Jan 15, 2012, 10:45:52 AM1/15/12
to
There is an error in the what I wrote below.
Number of Frames is an IS VR, not US like Rows and
Columns, so the limit for the largest +ve value is actually
(2^31)-1, which is 2,147,483,647, which is quite a
lot of frames.
Which means that for a compressed (encapsulated) video
stream the theoretical limits are that number of frames,
and/or the fragment size (if the transfer syntax
requires only one fragment for the whole stream, as
is the case for the MPEG transfer syntaxes).
A practical limit may be the largest file that the PACS
can create; hopefully with modern filesystems that
is not a factor at the filesystem level, but tool kits
using read/write/seek calls may have limits in offset
sizes if they are 32 bit signed or unsigned integers.
David
Number of Frames is an IS VR, not US like Rows and
Columns, so the limit for the largest +ve value is actually
(2^31)-1, which is 2,147,483,647, which is quite a
lot of frames.
Which means that for a compressed (encapsulated) video
stream the theoretical limits are that number of frames,
and/or the fragment size (if the transfer syntax
requires only one fragment for the whole stream, as
is the case for the MPEG transfer syntaxes).
A practical limit may be the largest file that the PACS
can create; hopefully with modern filesystems that
is not a factor at the filesystem level, but tool kits
using read/write/seek calls may have limits in offset
sizes if they are 32 bit signed or unsigned integers.
David
greggy
Jan 16, 2012, 2:51:46 PM1/16/12
to
Thanks for your answers all. I think after reading them I realized
that I need to ask what do colonoscopy modalities do with video that
they may generate? Do they only store relevant segments of video? Do
they store the entire video, but compress reduce frame rate? Do they
just use the video at the end of the procedure as a source of review
and then delete it? Do they store the video on external media apart
from the PACS?
that I need to ask what do colonoscopy modalities do with video that
they may generate? Do they only store relevant segments of video? Do
they store the entire video, but compress reduce frame rate? Do they
just use the video at the end of the procedure as a source of review
and then delete it? Do they store the video on external media apart
from the PACS?
0 new messages