Announcement

Collapse
No announcement yet.

summary: uncompressed video

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • summary: uncompressed video

    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
    -----------------------------------------------------------------
Working...
X