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

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]?

Bob Myers...

You still don't get it. A one-bit "file," no matter how it
was produced, can provide only one bit of information.

Radium...

I never said the file size is 1 bit. The file size is 193 bits.

Bob Myers...

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,

Radium...

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?

NoSpam...

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
Home of DaqGen, the FREEWARE signal generator

Martin Heffels...

Do yourself a favour, and play with the bit-depth of your computer-screen
and then play a movie. You will find the answer yourself.....
If the video is compressed down to 1 bit, it will be black or white, no
colour, no grey, no nothing. It's as simple as that :-)

davem...

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.

Radium...

I think this is what I am describing. I could be wrong though.

Martin Heffels...

Hang on. One bit per pixel, means that it can only have one value. Of

Pasi Ojala...

If you have some kind of predictor coding, one input bit is
capable of much more than monochrome.

Martin Heffels...

That's why I mentioned a LUT, where you can make that bit to display
anything you want.

And, one bit per pixel _on average_ is capable of much more
still. Ever heard of arithmetic coding?

Martin Heffels...

Arithmetic has always been my weak point at school ;-)
But I'll have a look into it.

course with a LUT you could determine which value should be displayed.

Bob Myers...

No, again, you're missing that all-important phrase "on average."
Talking about systems that use an AVERAGE of one bit per
pixel (or even less!) over the whole data stream doesn't really
tell you anything about the quality of the video being presented.
As was already discussed, standard HDTV operates at a data
rate such that there is, ON AVERAGE, less than one bit in the
transmitted data stream per pixel of the original X x Y pixel,
N frames per second video.

How that is achieved is actually quite clever...;-)

Bob M.

Ken Maltby...

Could you provide a reference to where such discussions
are going on? A paper perhaps, a journal?

Bob Myers...

Consider the following - the average data rate of an ATSC
digital television broadcast cannot exceed about 19.4 Mbits/sec.
In one second, a 1920 x 1080, 60 Hz (2:1 interlaced) HDTV
source generates at least:

1920 x 1080 x 30 = 62.2 million pixels.

So we have a data stream giving us under 20 million bits
each second, which we're going to have to turn into over
60 million pixels. That's under 3 bits/pixel, on average.
Ain't compression wonderful? (And it often gets down
to an average rate of around a bit per pixel...)

Bob M.

Pete Fraser...

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.

Ken Maltby...

Even I could do better than that, but the point was that if
this annoying OP could be lead to such material he might
have a chance of gaining some better understanding of the
situation where a reference to a standard bitrate/color depth
like "one bit per pixel" doesn't mean "1-bit object data".

It took a series of threads by the OP before he was able to
post this thread with his still refusal to comprehend that you
can't create a *FILE* compressed to just one bit of "object
data" and some overhead. Not for 2 hours of video, not for
2 seconds, not for HD, not for SD. Not a WMV, or AVI,
or MPEG. Not with wavelet compression, or any other way.
You can't have:
"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]?"

This FILE wouldn't be 193 bits in size. This FILE couldn't
exist. Too suggest otherwise, is only encouraging this folly. I
fully expect this OP to keep up his series of incremental
postings, on this matter, rather than crack a book, or even
web-search for a published reference, but we need not waste
too much time trying to straighten out his misconceptions.
The information is out there for OP to find with a little real
effort on his part.

Luck;
Ken

Luck;
Ken

Bob Myers...

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).

Radium...

How about a video whose "object data" bit-rate is a CBR of 1 bit per
second with a sample-rate of 148.5 mhz and 1920 X 1080 progressive scan
image resolution? How would this video look like? In 2 hours of this
video, the file size would be 7,200 bits. Sounds like a good idea for
internet video streaming -- if it is possible to have a bit-rate of 1
bit per second.

Bob Myers...

Doesn't matter. Again, the compressed stream is delivering data
at a rate which, relative to the original pixel rate, represents less
than one bit per pixel on average.

Now, it turns out that the numbers I picked in my example were
not (surprise, surprise!) chosen completely at random:

19.39 Mbit/sec is the actual data rate limit specified in the ATSC
(U.S. digital/HD TV) broadcast transmission standard.

1920 x 1080 at 30 frames/second, is, of course, a standard HD
format and frame rate. As it happens, such material is generally

Bob Myers...

Doesn't matter whether you talk about bits, bytes, words,
characters, or squamishes (a word I just stole from an old
Mad magazine to refer to data organized in 43-bit chunks).
You start out with this many bits, you wind up with this many
bits. It's just that "average bits per displayed pixel" has been
one of those fun ways of presenting compression ratio
information, especially in seminars where the objective of
the presenter is to elicit a "wow!" response from the audience
which is presumably learning about this stuff for the first time.

And you're never simply throwing away bits or bytes in
any practical compression scheme which is currently in
use; that would be far too crude. What happens in real-
world systems is far more complicated, and produces a
far better result.

Bob M.

originated as RGB data at at least 8 bits/color (24 bits/pixel);
long before getting to the compressed form of the final data
stream, it will most likely be re-encoded as YCbCr at something
less than a 4:4:4 sampling scheme - probably 4:2:2 or even 4:2:0
(which are systems that effectively reduce the spatial resolution
of the color components, while preserving the luminance component
at full resolution - this is itself a form of lossy compression vs. the
original RGB representation). The result then goes through a goodly
number of further compression processes, which results in the
cumulative data-rate reduction (compression ratio) seen in the end
result - something in the neighborhood of 80:1 vs. the original.

Bob M.

Bob M.

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.

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.

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