Tweet
Thank you very much all who responded.
Regards, Tomislav.
ORIGINAL QUESTION:
Dear All,
Concerning recent discussion about camera compression/storage issue I'd like to ask you the following question. Frequently I came across expression claiming that some video cameras are able to 'save streaming uncompressed video directly to disk'. What bothers me here is word 'uncompressed'. If we take cameras (effective) CCD to be 640x480 pixels size we end up with 307200 pixels. Then each pixel is granted 3 bytes for color which leads to amount of information 307200*3=921600 bytes, or 921600/1024=900KB, or 900/1024=0.8789MB. That is how much you are going to get if you take still photo (bmp file) with your digital photographic (video)camera. Now, 25frames progressive video camera would need to handle 25 of those images in second, meaning that 0.8789*25=21.97MB need to be sent via firewire on hard disk. Theoretical speed of firewire is 400MBits/seconds which is roughly twice as needed for above data. However to my knowledge realistic read/write speeds of most commercial hard drives can be expected around 20-30MB, which is pretty optimistic (try diagnostic toll SisSoft Sandra). If CCD sensor is of even greater size things becomes even more suspicious.
1. Thus, do 'streaming uncompressed video cameras' really have no compression at all or some takes place right at the CCD sensor?
2. Is it possible to save uncompressed above data on tape too ( I have no idea how inert is tape saving mechanism on cameras ). If so, then it should be no problem to grab those video images on disk, but of course not in real (playback) time if our disks are not ready for it!?
Thank you.
Regards, Tomislav
Tomislav Pribanic, M.Sc., EE
Department for Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
3 Unska, 10000 Zagreb, Croatia
tel. ..385 1 612 98 67, fax. ..385 1 612 96 52
E-mail : tomislav.pribanic@fer.hr
RESPONSE1:
Dear all,
This is an interesting discussion, but I think we would all agree that it is also quite confusing. I wonder if I might add some structure.
It seems to me there are three issues:
1. Method of recording - AVI or MPEG: MPEG 2 or 4
2. Method of storage - tape (analog or digital) or digital video file
3. Level of compression
In answer to Tomislav, I think there is a light compression applied to all recorded video, called YUV, which compresses shades of gray or luminance, called Y, and two chrominance values called U and V. The U vector points approximately in the red direction while the V vector points approximately in the blue direction. Any color can be converted from its RGB representation to its YUV values using a simple matrix transformation. The advantage to this approach is that the Y value can be digitized at full resolution while the U and V can be digitized at lower resolutions because the eye (and fortunately biomechanical analysis!) is not so sensitive to this information.
In my view, AVI (or QuickTime) is much preferable as he recording format because it can be easily edited. Due to the way it is compressed, MPEG files cannot easily (at all?) be pulled apart, making them difficult to edit. On the other hand, MPEG can be much more heavily compressed - mind you, I would suggest that we don't really want this for biomechanical purposes.
With regard to storage medium, I agree wholeheartedly with Rick Hinrichs that it is far better to have the video recorded directly to computer file, otherwise the downloading and conversion can be very tedious. I also think that it encourages the user to edit the data at the time of recording, whihc is much more efficent - most biomechanical movements are quite short. So, for me, the camera (or card) should record directly to disk or other digital storage medium. For this reason, I don't think FireWire is helpful. The same applies to using a card in the computer - OK for static setups, but I think most people are looking for a standalone solution.
I am personally always looking for a camera which is capable of recording short (up to, say 3 minutes or so) sequences at maximum digital frame rate (30 frames per second) with light compression to a SmartCard or mini-hard disk. I think this would be ideal for our purposes. To my knowledge, there's nothing yet out there which satisfies this spec, although the camera that I mentioned seems closest. I used to have a Hitachi MPEGCam 5 years ago (I think it is no longer on the market) which did this, but I had editing problems because of the MPEG format. Note that any camera will also have to have a fast, manual shutter speed and not suffer from the hibernation problem already mentioned. I carry a Fujifilm Finepix with me for still pictures which records short videos, but these are only 12 fps. I once tried the full "SLR" S7000 version which did seem to
record at 30 fps but was quite costly.
It is all very frustrating, but I really think that we are all waiting for Godot until such a camera comes along!
Chris
RESPONSE2:
Quick comment:
Be careful with terminology with respect to video formats. AVI and
Quicktime are "containers" for video - they are not specifically linked to
any compression format. AVI and MOV files can be uncompressed, or
compressed with a variety of methods (mpeg-2, mpeg-4, cinepak, DV, Windows
video, etc.).
Most compressed formats can be imported into professional-grade video
editing programs (Adobe Premiere, Avid Xpress, Apple Final Cut Pro, etc.)
and edited, and there is nothing inherently bad about mpeg compression.
But, different compression algorithms (and degrees of compression within an
algorithm) will introduce different kinds of errors for quantitative
analysis. Also, uncompressing, editing and then recompressing files creates
additional artifacts.
I disagree with the negative comments about firewire acquisition. The
compression used for DV-format video files is mild, and probably well-suited
for quantitative analysis. DV-format files can be retrieved from any
mini-DV camcorder with a firewire output, and you get the same quality video
whether you do a live firewire import from the video camera, or play back
the tape via firewire after recording is done. Also, inexpensive versions
of the professional editing programs are available for dealing with
DV-format video (e.g. Final Cut Express, Avid Xpress DV). Camcorders with a
progressive-scan mode are preferable, to eliminate interlace issues. DV
imports create large video files, but recordable CDs and DVDs are cheap
these days. I would be wary of using any additional compression for
quantitative applications unless I had performed an analysis of the effects
of the compression on measurement accuracy.
Scott
_______________________________
Scott Tashman, Ph.D.
Head, Motion Analysis Section
Bone and Joint Center
Henry Ford Hospital
2799 W. Grand Blvd, ER2015
Detroit, MI 48202
Voice: (313) 916-8680
FAX: (313) 916-8812
E-Mail: tashman@bjc.hfh.edu
RESPONSE3:
Dear Tomislav
The DV standard always transfers about 3.5 MB/s of COMPRESSED video.
3.5 MB/s is approx. 28 Mbit/s which considerably less than the maximum
Firewire transfer rate of 400 Mbit/s and with modern hard disks we easily
capture 4 or even 6 cameras to a single disk.
I guess that "uncompressed streaming" is meant to be "not recompressed".
Typical capture applications transfer the incoming data (without
modification) to a temporary file, called "capture file". After that the
user can select a portion of the clip and save this to another file.
Some applications allow to RECOMPRESS the portion of the video, using DIVX
or Intel Indeo or any other codec, including the "uncompressed images"
codec. Of course the the best quality is achieved with no recompression.
"Uncompressed images" have the same quality as the original clip but need
MUCH more space.
If your codec is running fast enough you can recompress the video
"on-the-fly".
Codecs shipped with Windows are too slow, produce poor quality and big
files.
Some MPEG-2 or MPEG-4 codecs are fast enough (as well as DIVX).
Some cameras allow "DV-in": Copying your clips to and from the tape will not
change the quality as long as no recompression is done. This is a main
advantage in comparison to analog video where each copy process will reduce
quality.
Regards,
Thomas.
Thomas Seeholzer
SIMI Reality Motion Systems GmbH
Tel: +49 89 321459-0
Fax: +49 89 321459-16
Mail: seeholzer@simi.com
Web: http://www.simi.com
RESPONSE4:
Tomislav Pribanic asked:
> Frequently I came across expression claiming that some video cameras
> are able to 'save streaming uncompressed video directly to disk'. What
> bothers me here is word 'uncompressed'.
If we're going to talk about specific bandwidths and terminology let's
talk about specific cameras:
Imaging Source DFK21F01, 640x480, 1CCD color, IEEE1394 bus, DCAM
protocol, no audio
http://www.1394imaging.com/products/cameras/dfk21f04/
?sid=c0e2650cd4c10b44d1ff13d2d00fbda2
> If we take cameras (effective) CCD to be 640x480 pixels size we end up
> with 307200 pixels. Then each pixel is granted 3 bytes for color which
> leads to amount of information 307200*3=921600 bytes, or
> 921600/1024=900KB, or 900/1024=3D0.8789MB. That is how much you are
> going to get if you take still photo (bmp file) with your digital
> photographic (video)camera.
Thankfully, video cameras don't use BMP or 24 bits per pixel for
colour. Instead they can use 8 (monochromatic), 12 (YUV 4:1:1), 16
(monochromatic or YUV 4:2:2), or 24 bits per pixel. This is one way to
reduce the video bandwidth: appropriate representation to achieve
reduced bits per channel.
The Imagining Source has a table of CDD sizes, bits per pixel and
frames per second achievable on a firewire bus:
http://www.1394imaging.com/resources/backgnd/1394/video_bandwidth/
For example, one DFK21F01, 640x480 on a firewire bus:
- 8 bits/pixel monochome is 64% of the bus bandwidth at 60fps,
- 12 bits/pixel YUV 4:1:1 is 48% of the bus at 30fps
- 16 bits/pixel YUV 4:2:2 is 64% of the bus at 30fps
- 24 bits/pixel RGB is 96% of the bus at 30fps
> Now, 25frames progressive video camera would need to handle 25 of
> those images in second, meaning that 0.8789*25=21.97MB need to be sent
> via firewire on hard disk.
> Theoretical speed of firewire is 400MBits/seconds which is roughly
> twice as needed for above data. However to my knowledge realistic
> read/write speeds of most commercial hard drives can be expected
> around 20-30MB, which is pretty optimistic (try diagnostic toll
> SisSoft Sandra). If CCD sensor is of even greater size things becomes
> even more suspicious.
Your HDD numbers sound like they are for an ATA 7200RPM HDD -- typical
for a new workstation. Serial ATA supports up to 150MB/sec (but you
may have trouble finding HDD to match that maximum bandwidth).
The solution is to use (a) faster HDD (SCSI 1000RPM), (b) and RAID:
multiple HDD (eg 4) each taking a fraction of the bandwidth. We have a
Ultra 160 SCSI RAID0 enclosure at UBC purchased in 1999 that supports
1000MB/sec read and 500MB/sec writes for video editing.
> 1. Thus, do 'streaming uncompressed video cameras' really have no
> compression at all or some takes place right at the CCD sensor?
You can get them in all possible flavors (RGB, YUV, monochrome)
> 2. Is it possible to save uncompressed above data on tape too ( I have
> no idea how inert is tape saving mechanism on cameras ). If so, then
> it should be no problem to grab those video images on disk, but of
> course not in real (playback) time if our disks are not ready for it!?
I don't expect that tape would have the bandwidth available for
uncompress video recording -- I think DV and D1 are designed for RAID
HDD arrays rather than tape. There are special busses for D1 and
DigiBeta (eg, SDI). Firewire is sort of like "prosumer USB" -- it
solves many of the same problems but is not designed for all purposes
(eg, the length of Firewire cables is limited to 3m, but you can use
hubs or string longer cables if you dare). I expect that most "high
performance serial" transfer busses will eventually shift to fiber
optics to avoid impedance delays in copper. You can get Firewire to
fiber translators but they are very expensive (USD$1500).
Further reading:
http://videosystems.com/ar/video_trailblazing_cards_mac/
-Jason
------------------------------------------------------------------------
-----
Jason Harrison, PhD
Post-Doctoral Fellow and Imager Lab Manager
Imager Laboratory for Computer Graphics, Visualization and HCI
FSC3640 - 2424 Main Mall, Vancouver BC V6T 1Z4
Cell: 604 644 8611 Lab: 604 822 2218; Fax: 604 822 8989
Web: http://www.cs.ubc.ca/~harrison
RESPONSE5:
On Friday, November 14, 2003, at 02:20 AM, Tomislav Pribanic wrote:
Hi Tomislav,
Hopefully I'll continue to get the answers correct!
>> If we're going to talk about specific bandwidths and terminology let's
>> talk about specific cameras:
> I could check myself for this one, but maybe you can svae me some
> time. Are
> you aware of any set of cameras (preferably sensitive tio infaraed
> markers)
> with acomppayning hardware for grabbing/synchoronization ready to buy
> and
> use. Namely, if I would like to set up 3D reconstruction kinematic
> system
> and have all neded software from the point where synchorinized
> (infrared)
> camera system images are saved to disk, where could I start looking for
> apropriate hardware?
All CCD cameras are sensitive to infrared -- you can test this by
taking a TV remote control which uses IR and point it at the camera and
press a button. You will see a very bright "light" on the camera
monitor which is invisible to your eyes if you look directly at the
remote. Sometimes camera manufacturers will put an IR filter
(blocking) on their lenses to decrease this sensitivity, but all CCDs
are sensitive to IR.
What you are looking for is a "motion capture system" -- one such
system is made by Vicon, www.vicon.com -- we have recently purchased
one of their systems but have not yet unpacked it.
Motion capture systems use a variety of markers (passive
retroreflective or active strobbed IR sources) but most of them tend to
send only a subset of the video information back to the computer
because the important task is to capture the motion of the markers.
The Vicon system can be outfitted with a DV camera so that you can
compare the "video" to the "motion".
>> Thankfully, video cameras don't use BMP or 24 bits per pixel for
>> colour. Instead they can use 8 (monochromatic), 12 (YUV 4:1:1), 16
>> (monochromatic or YUV 4:2:2), or 24 bits per pixel. This is one way
>> to
>> reduce the video bandwidth: appropriate representation to achieve
>> reduced bits per channel.
> I am not quite sure if I understand. Do cameras use 24 bit per pixel
> or not?
> Or is it meant that those 24 bits per pixel are not used all for color
> itself?
> Besides, can YUV can be considered then as mean of video compression
> and if
> so does in fall into category of mpegs#?
Oops, should be "Thankfully, video cameras do not all use BMP or 24
bits per pixel" -- that is you have a choice as to how many bits. If
RGB colour is not what you are interested in -- for example you are
only interested in infrared an 8 bit monochromatic image will tell you
the same thing with fewer bits.
YUV is a form of video compression that falls under the category of
"correct representation" -- For example, you could represent a sound
using 8 bits linearly mapped to amplitude but it would be better to use
8 bits logarithmically mapped to amplitude to better represent/capture
the quiet sounds. YUV 4:1:1 says to use 4 times as many bits intensity
as on colour,
>> The Imagining Source has a table of CDD sizes, bits per pixel and
>> frames per second achievable on a firewire bus:
> Some previous mail/comments calimed that DV standard always send via
> firewire 3.5MB/s, or 28Mbits/s which is 7% of firewire maximum. If
> thats
> true, how come that on the above link there is no such a video
> format/percentage combination. Precisley, the closest one is
> 160x120YUV(4:4:4), 6%. It would mean that all digital cameras have the
> corresponding format!? Or, Does it mean that DV standard does not
> always
> neceserally send 3.5MB7s.?
DV is 3.5MB/s period. It is a fixed rate encoding that does not lower
or increase the bandwidth regardless of what the camera is seeing.
Leave the lens cap on and you get 3.5MB/s, take the lens cap off and
point the camera at busy scene and you get 3.5MB/s.
None of the Imaging Source cameras encodes it's signal using DV.
>>> 1. Thus, do 'streaming uncompressed video cameras' really have no
>>> compression at all or some takes place right at the CCD sensor?
>>
>> You can get them in all possible flavors (RGB, YUV, monochrome)
>>
>>> 2. Is it possible to save uncompressed above data on tape too ( I
>>> have
>>> no idea how inert is tape saving mechanism on cameras ). If so, then
>>> it should be no problem to grab those video images on disk, but of
>>> course not in real (playback) time if our disks are not ready for
>>> it!?
>>
>> I don't expect that tape would have the bandwidth available for
>> uncompress video recording -- I think DV and D1 are designed for RAID
>> HDD arrays rather than tape. There are special busses for D1 and
> I toughth we agreed that there is no such thing as ideally uncompressed
> video (ideally uncompressed would be if I'd have bmp image for every
> frame/filed?)?
"ideally uncompressed" is a horrible term. There is lossy compression
and non-lossy compression and everything in between. PNG is a file
format for static images that does non-lossy compress of images. In
exchange for some computation you get a smaller image file than BMP.
BMP is a "horrible" image format because it is one of the laziest,
most primitive, image file formats you can find. However it may be
easier to write programs for reading, writing, and manipulating BMP
images than PNG files.
Ideally what you would have would be a non-lossy compressed sequence of
image files, or one AVI/QuickTime file containing all of the images
with no additional frame to frame compression. DV is very very close
to this. The image artifacts are very minimal, do not include frame to
frame relationships (which makes editing somewhat more difficult) and
while the video bandwidth is large, it is not impossible to deal with.
> Right after the scene falls on CCD senzor some compression
> always takes place, perhaps more when you save on tape rather then
> directly
> on disk. However, if you digital camera compresses with the same
> amount for
> both tape and disk then there should be no difference in quality if
> you grab
> your (digital) video later on from tape. Am I right?
Yes. Depending on the DV camcorder, they can either output a DV signal
immediately or by first recording to tape then playing back. The less
you pay for a DV camcorder, the fewer features and circuitry you will
get, and one of the first pieces of circuitry that is removed as you
pay less is the circuitry that allows DV output in real time without
recording.
For more information on Digital Video I suggest you read the Adobe DV
Primer, http://www.adobe.com/motion/primers.html
I don't have a good site to send you for motion capture, but the Vicon
website, www.vicon.com or googling for "motion capture" will give you
lots of pages.
-Jason
------------------------------------------------------------------------
-----
Jason Harrison, PhD
Post-Doctoral Fellow and Imager Lab Manager
Imager Laboratory for Computer Graphics, Visualization and HCI
FSC3640 - 2424 Main Mall, Vancouver BC V6T 1Z4
Cell: 604 644 8611 Lab: 604 822 2218; Fax: 604 822 8989
Web: http://www.cs.ubc.ca/~harrison
RESPONSE 6:
Dear Tomislav
There is a big difference between DV cameras (PAL, NTSC standard) and other
digital cameras.
The cameras described at 1394imaging.com are not DV cameras as they do not
apply to the "video" standard.
They transfer "uncompress data" with a high data rate.
DV cameras transfer a compressed video stream. They use a MJPEG algorithm
and compress the data to 3.5 MB/s. The same amount of data is written to the
DV tape. You can record to tape or directly to the computer, transfer the
video back to the tape and read it again: Data will be identical in all
cases.
The user cannot modify or bypass the compression algorithm.
As far as I can see the 1394imaging cameras do provide less than 50 Hz which
is not suitable for most biomechanical purposes.
SIMI implemented some cameras from BASLER (301f and 601f) into our system.
They provide up to 100 Hz (640x480, color) but you cannot capture these
cameras with normal DirectX software. We developed our own software to
capture these cameras. Their data rate is 30 MB/s per camera (!).
Bye,
Thomas Seeholzer
SIMI Reality Motion Systems GmbH
Tel: +49 89 321459-0
Fax: +49 89 321459-16
Mail: seeholzer@simi.com
Web: http://www.simi.com
-----------------------------------------------------------------
To unsubscribe send SIGNOFF BIOMCH-L to LISTSERV@nic.surfnet.nl
For information and archives: http://isb.ri.ccf.org/biomch-l
Web-based discussion forum: http://movement-analysis.com/biomch_l
-----------------------------------------------------------------
Regards, Tomislav.
ORIGINAL QUESTION:
Dear All,
Concerning recent discussion about camera compression/storage issue I'd like to ask you the following question. Frequently I came across expression claiming that some video cameras are able to 'save streaming uncompressed video directly to disk'. What bothers me here is word 'uncompressed'. If we take cameras (effective) CCD to be 640x480 pixels size we end up with 307200 pixels. Then each pixel is granted 3 bytes for color which leads to amount of information 307200*3=921600 bytes, or 921600/1024=900KB, or 900/1024=0.8789MB. That is how much you are going to get if you take still photo (bmp file) with your digital photographic (video)camera. Now, 25frames progressive video camera would need to handle 25 of those images in second, meaning that 0.8789*25=21.97MB need to be sent via firewire on hard disk. Theoretical speed of firewire is 400MBits/seconds which is roughly twice as needed for above data. However to my knowledge realistic read/write speeds of most commercial hard drives can be expected around 20-30MB, which is pretty optimistic (try diagnostic toll SisSoft Sandra). If CCD sensor is of even greater size things becomes even more suspicious.
1. Thus, do 'streaming uncompressed video cameras' really have no compression at all or some takes place right at the CCD sensor?
2. Is it possible to save uncompressed above data on tape too ( I have no idea how inert is tape saving mechanism on cameras ). If so, then it should be no problem to grab those video images on disk, but of course not in real (playback) time if our disks are not ready for it!?
Thank you.
Regards, Tomislav
Tomislav Pribanic, M.Sc., EE
Department for Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
3 Unska, 10000 Zagreb, Croatia
tel. ..385 1 612 98 67, fax. ..385 1 612 96 52
E-mail : tomislav.pribanic@fer.hr
RESPONSE1:
Dear all,
This is an interesting discussion, but I think we would all agree that it is also quite confusing. I wonder if I might add some structure.
It seems to me there are three issues:
1. Method of recording - AVI or MPEG: MPEG 2 or 4
2. Method of storage - tape (analog or digital) or digital video file
3. Level of compression
In answer to Tomislav, I think there is a light compression applied to all recorded video, called YUV, which compresses shades of gray or luminance, called Y, and two chrominance values called U and V. The U vector points approximately in the red direction while the V vector points approximately in the blue direction. Any color can be converted from its RGB representation to its YUV values using a simple matrix transformation. The advantage to this approach is that the Y value can be digitized at full resolution while the U and V can be digitized at lower resolutions because the eye (and fortunately biomechanical analysis!) is not so sensitive to this information.
In my view, AVI (or QuickTime) is much preferable as he recording format because it can be easily edited. Due to the way it is compressed, MPEG files cannot easily (at all?) be pulled apart, making them difficult to edit. On the other hand, MPEG can be much more heavily compressed - mind you, I would suggest that we don't really want this for biomechanical purposes.
With regard to storage medium, I agree wholeheartedly with Rick Hinrichs that it is far better to have the video recorded directly to computer file, otherwise the downloading and conversion can be very tedious. I also think that it encourages the user to edit the data at the time of recording, whihc is much more efficent - most biomechanical movements are quite short. So, for me, the camera (or card) should record directly to disk or other digital storage medium. For this reason, I don't think FireWire is helpful. The same applies to using a card in the computer - OK for static setups, but I think most people are looking for a standalone solution.
I am personally always looking for a camera which is capable of recording short (up to, say 3 minutes or so) sequences at maximum digital frame rate (30 frames per second) with light compression to a SmartCard or mini-hard disk. I think this would be ideal for our purposes. To my knowledge, there's nothing yet out there which satisfies this spec, although the camera that I mentioned seems closest. I used to have a Hitachi MPEGCam 5 years ago (I think it is no longer on the market) which did this, but I had editing problems because of the MPEG format. Note that any camera will also have to have a fast, manual shutter speed and not suffer from the hibernation problem already mentioned. I carry a Fujifilm Finepix with me for still pictures which records short videos, but these are only 12 fps. I once tried the full "SLR" S7000 version which did seem to
record at 30 fps but was quite costly.
It is all very frustrating, but I really think that we are all waiting for Godot until such a camera comes along!
Chris
RESPONSE2:
Quick comment:
Be careful with terminology with respect to video formats. AVI and
Quicktime are "containers" for video - they are not specifically linked to
any compression format. AVI and MOV files can be uncompressed, or
compressed with a variety of methods (mpeg-2, mpeg-4, cinepak, DV, Windows
video, etc.).
Most compressed formats can be imported into professional-grade video
editing programs (Adobe Premiere, Avid Xpress, Apple Final Cut Pro, etc.)
and edited, and there is nothing inherently bad about mpeg compression.
But, different compression algorithms (and degrees of compression within an
algorithm) will introduce different kinds of errors for quantitative
analysis. Also, uncompressing, editing and then recompressing files creates
additional artifacts.
I disagree with the negative comments about firewire acquisition. The
compression used for DV-format video files is mild, and probably well-suited
for quantitative analysis. DV-format files can be retrieved from any
mini-DV camcorder with a firewire output, and you get the same quality video
whether you do a live firewire import from the video camera, or play back
the tape via firewire after recording is done. Also, inexpensive versions
of the professional editing programs are available for dealing with
DV-format video (e.g. Final Cut Express, Avid Xpress DV). Camcorders with a
progressive-scan mode are preferable, to eliminate interlace issues. DV
imports create large video files, but recordable CDs and DVDs are cheap
these days. I would be wary of using any additional compression for
quantitative applications unless I had performed an analysis of the effects
of the compression on measurement accuracy.
Scott
_______________________________
Scott Tashman, Ph.D.
Head, Motion Analysis Section
Bone and Joint Center
Henry Ford Hospital
2799 W. Grand Blvd, ER2015
Detroit, MI 48202
Voice: (313) 916-8680
FAX: (313) 916-8812
E-Mail: tashman@bjc.hfh.edu
RESPONSE3:
Dear Tomislav
The DV standard always transfers about 3.5 MB/s of COMPRESSED video.
3.5 MB/s is approx. 28 Mbit/s which considerably less than the maximum
Firewire transfer rate of 400 Mbit/s and with modern hard disks we easily
capture 4 or even 6 cameras to a single disk.
I guess that "uncompressed streaming" is meant to be "not recompressed".
Typical capture applications transfer the incoming data (without
modification) to a temporary file, called "capture file". After that the
user can select a portion of the clip and save this to another file.
Some applications allow to RECOMPRESS the portion of the video, using DIVX
or Intel Indeo or any other codec, including the "uncompressed images"
codec. Of course the the best quality is achieved with no recompression.
"Uncompressed images" have the same quality as the original clip but need
MUCH more space.
If your codec is running fast enough you can recompress the video
"on-the-fly".
Codecs shipped with Windows are too slow, produce poor quality and big
files.
Some MPEG-2 or MPEG-4 codecs are fast enough (as well as DIVX).
Some cameras allow "DV-in": Copying your clips to and from the tape will not
change the quality as long as no recompression is done. This is a main
advantage in comparison to analog video where each copy process will reduce
quality.
Regards,
Thomas.
Thomas Seeholzer
SIMI Reality Motion Systems GmbH
Tel: +49 89 321459-0
Fax: +49 89 321459-16
Mail: seeholzer@simi.com
Web: http://www.simi.com
RESPONSE4:
Tomislav Pribanic asked:
> Frequently I came across expression claiming that some video cameras
> are able to 'save streaming uncompressed video directly to disk'. What
> bothers me here is word 'uncompressed'.
If we're going to talk about specific bandwidths and terminology let's
talk about specific cameras:
Imaging Source DFK21F01, 640x480, 1CCD color, IEEE1394 bus, DCAM
protocol, no audio
http://www.1394imaging.com/products/cameras/dfk21f04/
?sid=c0e2650cd4c10b44d1ff13d2d00fbda2
> If we take cameras (effective) CCD to be 640x480 pixels size we end up
> with 307200 pixels. Then each pixel is granted 3 bytes for color which
> leads to amount of information 307200*3=921600 bytes, or
> 921600/1024=900KB, or 900/1024=3D0.8789MB. That is how much you are
> going to get if you take still photo (bmp file) with your digital
> photographic (video)camera.
Thankfully, video cameras don't use BMP or 24 bits per pixel for
colour. Instead they can use 8 (monochromatic), 12 (YUV 4:1:1), 16
(monochromatic or YUV 4:2:2), or 24 bits per pixel. This is one way to
reduce the video bandwidth: appropriate representation to achieve
reduced bits per channel.
The Imagining Source has a table of CDD sizes, bits per pixel and
frames per second achievable on a firewire bus:
http://www.1394imaging.com/resources/backgnd/1394/video_bandwidth/
For example, one DFK21F01, 640x480 on a firewire bus:
- 8 bits/pixel monochome is 64% of the bus bandwidth at 60fps,
- 12 bits/pixel YUV 4:1:1 is 48% of the bus at 30fps
- 16 bits/pixel YUV 4:2:2 is 64% of the bus at 30fps
- 24 bits/pixel RGB is 96% of the bus at 30fps
> Now, 25frames progressive video camera would need to handle 25 of
> those images in second, meaning that 0.8789*25=21.97MB need to be sent
> via firewire on hard disk.
> Theoretical speed of firewire is 400MBits/seconds which is roughly
> twice as needed for above data. However to my knowledge realistic
> read/write speeds of most commercial hard drives can be expected
> around 20-30MB, which is pretty optimistic (try diagnostic toll
> SisSoft Sandra). If CCD sensor is of even greater size things becomes
> even more suspicious.
Your HDD numbers sound like they are for an ATA 7200RPM HDD -- typical
for a new workstation. Serial ATA supports up to 150MB/sec (but you
may have trouble finding HDD to match that maximum bandwidth).
The solution is to use (a) faster HDD (SCSI 1000RPM), (b) and RAID:
multiple HDD (eg 4) each taking a fraction of the bandwidth. We have a
Ultra 160 SCSI RAID0 enclosure at UBC purchased in 1999 that supports
1000MB/sec read and 500MB/sec writes for video editing.
> 1. Thus, do 'streaming uncompressed video cameras' really have no
> compression at all or some takes place right at the CCD sensor?
You can get them in all possible flavors (RGB, YUV, monochrome)
> 2. Is it possible to save uncompressed above data on tape too ( I have
> no idea how inert is tape saving mechanism on cameras ). If so, then
> it should be no problem to grab those video images on disk, but of
> course not in real (playback) time if our disks are not ready for it!?
I don't expect that tape would have the bandwidth available for
uncompress video recording -- I think DV and D1 are designed for RAID
HDD arrays rather than tape. There are special busses for D1 and
DigiBeta (eg, SDI). Firewire is sort of like "prosumer USB" -- it
solves many of the same problems but is not designed for all purposes
(eg, the length of Firewire cables is limited to 3m, but you can use
hubs or string longer cables if you dare). I expect that most "high
performance serial" transfer busses will eventually shift to fiber
optics to avoid impedance delays in copper. You can get Firewire to
fiber translators but they are very expensive (USD$1500).
Further reading:
http://videosystems.com/ar/video_trailblazing_cards_mac/
-Jason
------------------------------------------------------------------------
-----
Jason Harrison, PhD
Post-Doctoral Fellow and Imager Lab Manager
Imager Laboratory for Computer Graphics, Visualization and HCI
FSC3640 - 2424 Main Mall, Vancouver BC V6T 1Z4
Cell: 604 644 8611 Lab: 604 822 2218; Fax: 604 822 8989
Web: http://www.cs.ubc.ca/~harrison
RESPONSE5:
On Friday, November 14, 2003, at 02:20 AM, Tomislav Pribanic wrote:
Hi Tomislav,
Hopefully I'll continue to get the answers correct!
>> If we're going to talk about specific bandwidths and terminology let's
>> talk about specific cameras:
> I could check myself for this one, but maybe you can svae me some
> time. Are
> you aware of any set of cameras (preferably sensitive tio infaraed
> markers)
> with acomppayning hardware for grabbing/synchoronization ready to buy
> and
> use. Namely, if I would like to set up 3D reconstruction kinematic
> system
> and have all neded software from the point where synchorinized
> (infrared)
> camera system images are saved to disk, where could I start looking for
> apropriate hardware?
All CCD cameras are sensitive to infrared -- you can test this by
taking a TV remote control which uses IR and point it at the camera and
press a button. You will see a very bright "light" on the camera
monitor which is invisible to your eyes if you look directly at the
remote. Sometimes camera manufacturers will put an IR filter
(blocking) on their lenses to decrease this sensitivity, but all CCDs
are sensitive to IR.
What you are looking for is a "motion capture system" -- one such
system is made by Vicon, www.vicon.com -- we have recently purchased
one of their systems but have not yet unpacked it.
Motion capture systems use a variety of markers (passive
retroreflective or active strobbed IR sources) but most of them tend to
send only a subset of the video information back to the computer
because the important task is to capture the motion of the markers.
The Vicon system can be outfitted with a DV camera so that you can
compare the "video" to the "motion".
>> Thankfully, video cameras don't use BMP or 24 bits per pixel for
>> colour. Instead they can use 8 (monochromatic), 12 (YUV 4:1:1), 16
>> (monochromatic or YUV 4:2:2), or 24 bits per pixel. This is one way
>> to
>> reduce the video bandwidth: appropriate representation to achieve
>> reduced bits per channel.
> I am not quite sure if I understand. Do cameras use 24 bit per pixel
> or not?
> Or is it meant that those 24 bits per pixel are not used all for color
> itself?
> Besides, can YUV can be considered then as mean of video compression
> and if
> so does in fall into category of mpegs#?
Oops, should be "Thankfully, video cameras do not all use BMP or 24
bits per pixel" -- that is you have a choice as to how many bits. If
RGB colour is not what you are interested in -- for example you are
only interested in infrared an 8 bit monochromatic image will tell you
the same thing with fewer bits.
YUV is a form of video compression that falls under the category of
"correct representation" -- For example, you could represent a sound
using 8 bits linearly mapped to amplitude but it would be better to use
8 bits logarithmically mapped to amplitude to better represent/capture
the quiet sounds. YUV 4:1:1 says to use 4 times as many bits intensity
as on colour,
>> The Imagining Source has a table of CDD sizes, bits per pixel and
>> frames per second achievable on a firewire bus:
> Some previous mail/comments calimed that DV standard always send via
> firewire 3.5MB/s, or 28Mbits/s which is 7% of firewire maximum. If
> thats
> true, how come that on the above link there is no such a video
> format/percentage combination. Precisley, the closest one is
> 160x120YUV(4:4:4), 6%. It would mean that all digital cameras have the
> corresponding format!? Or, Does it mean that DV standard does not
> always
> neceserally send 3.5MB7s.?
DV is 3.5MB/s period. It is a fixed rate encoding that does not lower
or increase the bandwidth regardless of what the camera is seeing.
Leave the lens cap on and you get 3.5MB/s, take the lens cap off and
point the camera at busy scene and you get 3.5MB/s.
None of the Imaging Source cameras encodes it's signal using DV.
>>> 1. Thus, do 'streaming uncompressed video cameras' really have no
>>> compression at all or some takes place right at the CCD sensor?
>>
>> You can get them in all possible flavors (RGB, YUV, monochrome)
>>
>>> 2. Is it possible to save uncompressed above data on tape too ( I
>>> have
>>> no idea how inert is tape saving mechanism on cameras ). If so, then
>>> it should be no problem to grab those video images on disk, but of
>>> course not in real (playback) time if our disks are not ready for
>>> it!?
>>
>> I don't expect that tape would have the bandwidth available for
>> uncompress video recording -- I think DV and D1 are designed for RAID
>> HDD arrays rather than tape. There are special busses for D1 and
> I toughth we agreed that there is no such thing as ideally uncompressed
> video (ideally uncompressed would be if I'd have bmp image for every
> frame/filed?)?
"ideally uncompressed" is a horrible term. There is lossy compression
and non-lossy compression and everything in between. PNG is a file
format for static images that does non-lossy compress of images. In
exchange for some computation you get a smaller image file than BMP.
BMP is a "horrible" image format because it is one of the laziest,
most primitive, image file formats you can find. However it may be
easier to write programs for reading, writing, and manipulating BMP
images than PNG files.
Ideally what you would have would be a non-lossy compressed sequence of
image files, or one AVI/QuickTime file containing all of the images
with no additional frame to frame compression. DV is very very close
to this. The image artifacts are very minimal, do not include frame to
frame relationships (which makes editing somewhat more difficult) and
while the video bandwidth is large, it is not impossible to deal with.
> Right after the scene falls on CCD senzor some compression
> always takes place, perhaps more when you save on tape rather then
> directly
> on disk. However, if you digital camera compresses with the same
> amount for
> both tape and disk then there should be no difference in quality if
> you grab
> your (digital) video later on from tape. Am I right?
Yes. Depending on the DV camcorder, they can either output a DV signal
immediately or by first recording to tape then playing back. The less
you pay for a DV camcorder, the fewer features and circuitry you will
get, and one of the first pieces of circuitry that is removed as you
pay less is the circuitry that allows DV output in real time without
recording.
For more information on Digital Video I suggest you read the Adobe DV
Primer, http://www.adobe.com/motion/primers.html
I don't have a good site to send you for motion capture, but the Vicon
website, www.vicon.com or googling for "motion capture" will give you
lots of pages.
-Jason
------------------------------------------------------------------------
-----
Jason Harrison, PhD
Post-Doctoral Fellow and Imager Lab Manager
Imager Laboratory for Computer Graphics, Visualization and HCI
FSC3640 - 2424 Main Mall, Vancouver BC V6T 1Z4
Cell: 604 644 8611 Lab: 604 822 2218; Fax: 604 822 8989
Web: http://www.cs.ubc.ca/~harrison
RESPONSE 6:
Dear Tomislav
There is a big difference between DV cameras (PAL, NTSC standard) and other
digital cameras.
The cameras described at 1394imaging.com are not DV cameras as they do not
apply to the "video" standard.
They transfer "uncompress data" with a high data rate.
DV cameras transfer a compressed video stream. They use a MJPEG algorithm
and compress the data to 3.5 MB/s. The same amount of data is written to the
DV tape. You can record to tape or directly to the computer, transfer the
video back to the tape and read it again: Data will be identical in all
cases.
The user cannot modify or bypass the compression algorithm.
As far as I can see the 1394imaging cameras do provide less than 50 Hz which
is not suitable for most biomechanical purposes.
SIMI implemented some cameras from BASLER (301f and 601f) into our system.
They provide up to 100 Hz (640x480, color) but you cannot capture these
cameras with normal DirectX software. We developed our own software to
capture these cameras. Their data rate is 30 MB/s per camera (!).
Bye,
Thomas Seeholzer
SIMI Reality Motion Systems GmbH
Tel: +49 89 321459-0
Fax: +49 89 321459-16
Mail: seeholzer@simi.com
Web: http://www.simi.com
-----------------------------------------------------------------
To unsubscribe send SIGNOFF BIOMCH-L to LISTSERV@nic.surfnet.nl
For information and archives: http://isb.ri.ccf.org/biomch-l
Web-based discussion forum: http://movement-analysis.com/biomch_l
-----------------------------------------------------------------