2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan image, 1-bit object data, 193 bits of file s

Discussion in 'Windows Media Player' started by Radium, Oct 27, 2006.

  1. Radium

    Radium Guest

    Michael Walraven wrote in
    http://groups.google.com/group/sci.electronics.basics/msg/67ea1a75d326e0f8?hl=en&
    :
    So is it possible to exist for the following to exist:

    A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
    image, whose object data is only 1-bit in size due to massive
    compression of color-depth? [this file would be 193 bits in size
    because the the "object size" is 64 bits, the GUID is 128 bits, and the
    object data is only 1-bit]?

    If such a WMV file can exist, how would its video look like?


    Thanks,

    Radium
     
    Radium, Oct 27, 2006
    #1
    1. Advertisements

  2. Radium

    Bob Myers Guest

    You still don't get it. A one-bit "file," no matter how it
    was produced, can provide only one bit of information.
    That SHOULD be obvious, but you're not thinking about
    what it means. A single bit can convey what amounts to ONE
    answer to a yes/no, or true/false sort of question - in other
    words, just enough information to permit one to decide
    between two and only two possible answers. That's why
    people have been, in jest, talking about the multi-gigabyte
    "decompression" routines your supposed "one bit" file would
    require - what they really mean is that the "decompression"
    program itself would have to contain all of the information
    required to reconstruct either of two (and not more than two)
    possible videos. Or in other words, you've just shifted the
    burden of providing the information from the "video file" to
    the "decompressor" - in effect, the "file" you're talking about
    is just identifying which of two videos (contained elsewhere)
    you want to see.

    As usual, you need to learn a LOT more about the fields you're
    trying to discuss (in this case, information theory and data
    compression) before you leap to these absurd notions.

    Bob M.
     
    Bob Myers, Oct 27, 2006
    #2
    1. Advertisements

  3. Radium

    Bob Myers Guest

    You still don't get it. A one-bit "file," no matter how it
    was produced, can provide only one bit of information.
    That SHOULD be obvious, but you're not thinking about
    what it means. A single bit can convey what amounts to ONE
    answer to a yes/no, or true/false sort of question - in other
    words, just enough information to permit one to decide
    between two and only two possible answers. That's why
    people have been, in jest, talking about the multi-gigabyte
    "decompression" routines your supposed "one bit" file would
    require - what they really mean is that the "decompression"
    program itself would have to contain all of the information
    required to reconstruct either of two (and not more than two)
    possible videos. Or in other words, you've just shifted the
    burden of providing the information from the "video file" to
    the "decompressor" - in effect, the "file" you're talking about
    is just identifying which of two videos (contained elsewhere)
    you want to see.

    As usual, you need to learn a LOT more about the fields you're
    trying to discuss (in this case, information theory and data
    compression) before you leap to these absurd notions.

    Bob M.
     
    Bob Myers, Oct 27, 2006
    #3
  4. Radium

    Radium Guest

    I never said the file size is 1 bit. The file size is 193 bits.
     
    Radium, Oct 27, 2006
    #4
  5. Radium

    Bob Myers Guest

    Radium, old chap, here's exactly what you said:

    "So is it possible to exist for the following to exist:

    A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
    image, whose object data is only 1-bit in size due to massive
    compression of color-depth? [this file would be 193 bits in size
    because the the "object size" is 64 bits, the GUID is 128 bits, and the
    object data is only 1-bit]?

    If such a WMV file can exist, how would its video look like?"

    You're clearly talking about the "object data" - i.e., all of the data
    outside of the required overhead - being just a single bit. That's
    the data that actually carries the video information, right? If not,
    then what exactly DID you mean by "the object data is only
    1 bit"?

    And given THAT, the analysis I gave you is both correct and
    relevant. You simply have no idea what you're talking about
    here - once again.

    Bob M.
     
    Bob Myers, Oct 27, 2006
    #5
  6. Radium

    Bob Myers Guest

    Radium, old chap, here's exactly what you said:

    "So is it possible to exist for the following to exist:

    A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
    image, whose object data is only 1-bit in size due to massive
    compression of color-depth? [this file would be 193 bits in size
    because the the "object size" is 64 bits, the GUID is 128 bits, and the
    object data is only 1-bit]?

    If such a WMV file can exist, how would its video look like?"

    You're clearly talking about the "object data" - i.e., all of the data
    outside of the required overhead - being just a single bit. That's
    the data that actually carries the video information, right? If not,
    then what exactly DID you mean by "the object data is only
    1 bit"?

    And given THAT, the analysis I gave you is both correct and
    relevant. You simply have no idea what you're talking about
    here - once again.

    Bob M.
     
    Bob Myers, Oct 27, 2006
    #6
  7. Radium

    Radium Guest

    Yes. The "object data" is the video signal. So I just got the point. As
    you say, one-bit would not work for this video. Then what is the
    minimum bit required?
     
    Radium, Oct 27, 2006
    #7
  8. Radium

    Bob Masta Guest

    I have the distinct impression that you are new to the concepts of
    compression. Here's a thumbnail sketch: All compression schemes
    can be divided into lossless and lossy. Lossless compression
    works by analyzing the data and replacing large redundant areas
    with smaller versions. For example, in a text file you might replace
    each occurence of 'the' with a single byte or symbol. The compressor
    also creates a "dictionary" table that allows you to determine the
    long form from the symbol. Then the decompressor reads a symbol
    and recreates the original.

    If you think about it, you should realize that there is no way to
    predict ahead of time how much compression is possible with
    this scheme. If your source has a lot of redundancy, the compression
    ratio is high. If the source is random data with no patterns, then
    no compression is possible (by defininition). So if you had a video
    taken with the lens cap on (all black) the compression would be
    extremely high... just a symbol for "black" and a run length. If
    you had a video of a swirling snowstorm (random black and white
    dots) the compression might be non-existent.

    But many real-world things like video and audio contain a lot
    more information than most people want. For example, in an
    audio recording, you probably don't care if the background hiss
    is *exactly* the same waveform as the original. You can't really
    tell one run of random hiss from another with the sme spectrum
    and level. Similarly, human ears are really bad at detecting
    absolute phase, or a soft sound in the presence of a loud one
    at a similar frequency, and a whole lot of other stuff. So lossy
    compression says, essentially, "if you can't tell the difference,
    don't bother to save the details". In the hiss case, for example,
    it could encode a few symbols to specify the spectrum, level,
    and duration. A program of pure background hiss that could
    not be compressed at all with lossless compression would
    thus compress down to a few symbols. In the real world, of
    course, we don't care about such cases. In concept, lossy audio
    compression works by looking at the spectrum of sound snippets
    and deciding which sounds would be masked by louder sounds
    in the same frequency region, and trims those out. Then it
    only has to store the frequencies and levels of the components
    you can actually hear.

    Another concept is to store only *changes* from one frame
    to the next, whether we are talking about audio or video.
    If everything is the same as the last frame, store a "ditto"
    symbol and run length for the total number of frames that
    are the same. If there is a small change, store only the
    part that is changed.

    So once again, you should see that there is no way to
    predict maximum compression for a real-world case.

    Hope that helps!


    Bob Masta
    dqatechATdaqartaDOTcom

    D A Q A R T A
    Data AcQuisition And Real-Time Analysis
    www.daqarta.com
    Home of DaqGen, the FREEWARE signal generator
     
    Bob Masta, Oct 27, 2006
    #8
  9. Radium

    Bob Masta Guest

    I have the distinct impression that you are new to the concepts of
    compression. Here's a thumbnail sketch: All compression schemes
    can be divided into lossless and lossy. Lossless compression
    works by analyzing the data and replacing large redundant areas
    with smaller versions. For example, in a text file you might replace
    each occurence of 'the' with a single byte or symbol. The compressor
    also creates a "dictionary" table that allows you to determine the
    long form from the symbol. Then the decompressor reads a symbol
    and recreates the original.

    If you think about it, you should realize that there is no way to
    predict ahead of time how much compression is possible with
    this scheme. If your source has a lot of redundancy, the compression
    ratio is high. If the source is random data with no patterns, then
    no compression is possible (by defininition). So if you had a video
    taken with the lens cap on (all black) the compression would be
    extremely high... just a symbol for "black" and a run length. If
    you had a video of a swirling snowstorm (random black and white
    dots) the compression might be non-existent.

    But many real-world things like video and audio contain a lot
    more information than most people want. For example, in an
    audio recording, you probably don't care if the background hiss
    is *exactly* the same waveform as the original. You can't really
    tell one run of random hiss from another with the sme spectrum
    and level. Similarly, human ears are really bad at detecting
    absolute phase, or a soft sound in the presence of a loud one
    at a similar frequency, and a whole lot of other stuff. So lossy
    compression says, essentially, "if you can't tell the difference,
    don't bother to save the details". In the hiss case, for example,
    it could encode a few symbols to specify the spectrum, level,
    and duration. A program of pure background hiss that could
    not be compressed at all with lossless compression would
    thus compress down to a few symbols. In the real world, of
    course, we don't care about such cases. In concept, lossy audio
    compression works by looking at the spectrum of sound snippets
    and deciding which sounds would be masked by louder sounds
    in the same frequency region, and trims those out. Then it
    only has to store the frequencies and levels of the components
    you can actually hear.

    Another concept is to store only *changes* from one frame
    to the next, whether we are talking about audio or video.
    If everything is the same as the last frame, store a "ditto"
    symbol and run length for the total number of frames that
    are the same. If there is a small change, store only the
    part that is changed.

    So once again, you should see that there is no way to
    predict maximum compression for a real-world case.

    Hope that helps!


    Bob Masta
    dqatechATdaqartaDOTcom

    D A Q A R T A
    Data AcQuisition And Real-Time Analysis
    www.daqarta.com
    Home of DaqGen, the FREEWARE signal generator
     
    Bob Masta, Oct 27, 2006
    #9
  10. Radium

    Quanta Guest

    A-men and Bravo!
     
    Quanta, Oct 27, 2006
    #10
  11. Radium

    Quanta Guest

    A-men and Bravo!
     
    Quanta, Oct 27, 2006
    #11
  12. Radium

    Bob Myers Guest

    There's no way of giving a single, absolute answer here - the
    minimum "file size" or "object data" size for any compressed
    information depends on the size, etc., of the original data, and
    the nature of the compression and the desired quality of the
    uncompressed result. Compression methods broadly fall into
    two categories - "lossless," in which case the compression itself
    does not degrade the data in any way (but it removes redundancy,
    making the data more vulnerable to loss through noise in the
    transmission channel), and "lossy," in which case you know there's
    going to be some loss of quality no matter what - the question is
    how much of a hit you're willing to take (which in turn often has
    to do with what can reasonably be expected to be heard/seen
    by the human user of this data).

    Bob M.
     
    Bob Myers, Oct 28, 2006
    #12
  13. Radium

    Bob Myers Guest

    There's no way of giving a single, absolute answer here - the
    minimum "file size" or "object data" size for any compressed
    information depends on the size, etc., of the original data, and
    the nature of the compression and the desired quality of the
    uncompressed result. Compression methods broadly fall into
    two categories - "lossless," in which case the compression itself
    does not degrade the data in any way (but it removes redundancy,
    making the data more vulnerable to loss through noise in the
    transmission channel), and "lossy," in which case you know there's
    going to be some loss of quality no matter what - the question is
    how much of a hit you're willing to take (which in turn often has
    to do with what can reasonably be expected to be heard/seen
    by the human user of this data).

    Bob M.
     
    Bob Myers, Oct 28, 2006
    #13
  14. "Radium" wrote...
    One bit would not work for ANY video.
    One bit would not work for any AUDIO.
    One bit would not work for any TEXT.

    One bit could tell you whether the porch light is on.
    One bit could tell you if you left the fridge door open.
    One bit could tell you if it is night or day.

    One bit = Yes or No. Nothing beyond that.
    How may frames per sec? 30? 24? 15? 6? 2? 1? 1 per minute?
    How much image degradation is acceptable?

    You might even be able to get it down to several MB,
    but nobody would want to watch it (or likely even
    recognize it.)

    Do you understand that your question is not answerable?
    Or are you just trolling us?
     
    Richard Crowley, Oct 28, 2006
    #14
  15. "Radium" wrote...
    One bit would not work for ANY video.
    One bit would not work for any AUDIO.
    One bit would not work for any TEXT.

    One bit could tell you whether the porch light is on.
    One bit could tell you if you left the fridge door open.
    One bit could tell you if it is night or day.

    One bit = Yes or No. Nothing beyond that.
    How may frames per sec? 30? 24? 15? 6? 2? 1? 1 per minute?
    How much image degradation is acceptable?

    You might even be able to get it down to several MB,
    but nobody would want to watch it (or likely even
    recognize it.)

    Do you understand that your question is not answerable?
    Or are you just trolling us?
     
    Richard Crowley, Oct 28, 2006
    #15
  16. Radium

    Radium Guest

    Okay. I understand.
    Frames per sec should not be decreased at all. The sample rate should
    still be 148.50 mhz.
    Infinite, as long as as the sample-rate [148.50 mhz], the frame-rate
    [60 hz], and the pixel-resolution [1920 X 1080 progressive] are not
    decreased. As for the color-depth, compress it as much as you want.
    Well, as long as the sample-rate, frame-rate, and pixel-resolution are
    not decreased, I don't mind maximum WMV compression of color-depth.
    Now I do.
    No.
     
    Radium, Oct 28, 2006
    #16
  17. Well, not, it's not. When someone is discussing image or video
    compression, and they refer to "one bit per pixel", they are almost
    certainly *not* talking about bilevel black&white display. Instead,
    they are talking about either a greyscale or colour image that has been
    sufficiently compressed that the *average* bit rate is 1 bit per
    pixel. But when the image is decompressed, it returns to some wider
    format; usually 8 bits for greyscale and 24 bits for colour.

    Dave
     
    Dave Martindale, Oct 28, 2006
    #17
  18. Well, not, it's not. When someone is discussing image or video
    compression, and they refer to "one bit per pixel", they are almost
    certainly *not* talking about bilevel black&white display. Instead,
    they are talking about either a greyscale or colour image that has been
    sufficiently compressed that the *average* bit rate is 1 bit per
    pixel. But when the image is decompressed, it returns to some wider
    format; usually 8 bits for greyscale and 24 bits for colour.

    Dave
     
    Dave Martindale, Oct 28, 2006
    #18
  19. Radium

    Pete Fraser Guest

    Looks at the documantation of almost any video or image
    compression tool.

    For example, the usage example for Kakadu (JPEG2000):

    a) kdu_compress -i image.pgm -o out.j2c -rate 1.0
    -- irreversible compression to 1 bit/sample.
     
    Pete Fraser, Oct 28, 2006
    #19
  20. Radium

    Pete Fraser Guest

    Looks at the documantation of almost any video or image
    compression tool.

    For example, the usage example for Kakadu (JPEG2000):

    a) kdu_compress -i image.pgm -o out.j2c -rate 1.0
    -- irreversible compression to 1 bit/sample.
     
    Pete Fraser, Oct 28, 2006
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.