OSDev.org

Isn't it theoretically possible to make a video of anything, given you know the right format, encoding, etc. (i.e. camera absent)?

We know (or better said, can know) how to draw a red square 24x24 pixels as a .BMP format or such without having to actually draw the image. It can be done byte-by-byte (or a program could do it) without ever having to draw that.

Although it's insane comparing the encoding format of an all red 24x24 .BMP to a 470 MB 1080p video with tens of thousands of frames, wouldn't this be possible?

For example (and simplicity), one could byte-by-byte write manually (or with the help of a computer program) a 2 second clip of water ripples at 20 frames per second in the simplest video format and smallest size possible, whilst still keeping details. The result would be encoding 40 frames non-interlaced colors detailing the ripple movements with, say, .AVI; no sound necessary.

One would need to concoct the (roughly) similar data of the desired shot, as to how it should be intended to look with regards to the physical manifestation of its encoding scheme based on lighting, colors, compression, etc. as captured by a camera.

Here are some image examples: (NOTE: these are examples of angles and physical manifestations of how water could be recorded, not of a video to actually be made in practice):

Diffraction/Top-View

Dark water; low-light

Clear blue light water (transparent)

Even-balanced

All that would also need to be know? Possibly color encoding formats, compression, etc.

If nobody understands what I'm talking about, I'm talking about byte-by-byte creating a representation of a video that can be played without actually having recorded anything (same as making a red square, or two red squares, as a .BMP without using MSPaint.exe). Yes, that means encoding the necessary color, frame, compression, etc. info by hand as a video camera or recording device would after capturing light from the aperture and encoding it digitally as some format (including playback capable, yes).

I just want some thoughts on this in similar manners:

1.Do you think this is theoretically possible and applicable in practice somehow, considering the simplest movement/video possible?

2.Any ideas on how this can be accomplished in this lifetime?

3.How many possibilities can there be in recording things (e.g. light capture, colors, etc. that can be encoded from observable light in a camera), and what's the simplest thing one can create like this (if not water ripples)?

The way I would go about doing this is to create the scene or animation like in a game or demo. Then when it can be played as a normal code driven animation just save each frame through a screen grabber, either as an external app or as an internal function/library.

What you're talking about sounds pretty much like vector graphics; in which case, yes. You can. Eg. flv and swf video formats.

Nope ... not vector graphics. I'm afraid my question may have not been clear enough.

Take this image for example: http://s28.postimg.org/51kyl0v2h/1x1.png (zoom in to see).

It's a 1x1 monochrome BMP file. This is what data makes up its format:

http://s17.postimg.org/iqm02nc5r/yep.jpg

It's possible to then know what data makes up the image format, and hand-edit a 1x1 black monochrome image.

When I recorded a video of my hand and uploaded it (640x480, AVI, 60 FPS) I get this:

http://s2.postimg.org/5ejm26cbt/hand.png

And so on I may extrapolate that data format and try to re-create this same data without having recorded it.

Hi,

In theory, given enough time, it's possible to create any file of any type one byte at a time by hand (e.g. including a "tar.gz" of your entire hard drive containing many movies).

In practice, there's no sane reason to bother and it's faster to use suitable "tools" (e.g. maybe Blender); even if that means writing your own software that generates the movie.


Cheers,

Brendan

Yeah, of course it's possible. How do you think CG graphics are made? It's generally done by generating a bunch of images and then encoding these into a video. I've used ffmpeg to turn a series of images into a video for lots of math based computations/simulations (n body problem, parametric ODE modelling, other graphing problems). If you wanted to go byte by byte, you'd basically just have to write code that does everything from the level of the simulation/computation to the image generation to the video encoding step by step (whereas the usual method is to do the computation, send the resulting data to the image generator, then send the images to the video encoder, b/c this is compartmentalized/cleaner/more extensible).

I don't know whether or not to assume anyone knows what I'm talking about, or to assume for the benefit of the doubt that most people may roughly have an idea of what exactly I am trying to get across.

I think I will go with the latter. I'm only saying this because people keep speaking of vector graphics, but byte data also encodes things that actually exist digitally (e.g. your grandmother on a rocking chair, a fish in a bowl, a dog in a yard).

With that in mind, I am more focused on the theory of producing indeterminate data that would otherwise be that encoding of which a camera may capture with the light of the real physical world. I do not know yet enough of how digital cameras encore the video data and captured footage, but my theory is that, if data could be created that looked just the same as, say, someone being axe murdered, but that data was created by hand using the right encoding based on the light and data observable from a camera by that scene, it is possible you can create otherwise "real" footage of which never happened.

If you're asking whether it would be computationally or "humanly" possible to generate a photo-realistic image from scratch, "byte to byte", then the answer is potato.

LieutenantHacker wrote:I think I will go with the latter. I'm only saying this because people keep speaking of vector graphics, but byte data also encodes things that actually exist digitally (e.g. your grandmother on a rocking chair, a fish in a bowl, a dog in a yard).

swf and flv vector flash video formats support mapping textures onto vertices like how you'd texture a 3d model.

LieutenantHacker wrote:With that in mind, I am more focused on the theory of producing indeterminate data that would otherwise be that encoding of which a camera may capture with the light of the real physical world. I do not know yet enough of how digital cameras encore the video data and captured footage

They usually encode it with JPEG/MPEG compression using built in hardware.

LieutenantHacker wrote:, but my theory is that, if data could be created that looked just the same as, say, someone being axe murdered, but that data was created by hand using the right encoding based on the light and data observable from a camera by that scene, it is possible you can create otherwise "real" footage of which never happened.

Ever heard of ray tracing?


EDIT:

Brynet-Inc wrote:If you're asking whether it would be computationally or "humanly" possible to generate a photo-realistic image from scratch, "byte to byte", then the answer is potato.

Oh? But bytes are binary. Shouldn't 2+2=fish?

Digital photos are elaborate illusions, representations of the world encoded digitally by an image sensor (CMOS/etc) and compressed. The information becomes less intelligible and more like random noise the closer you "observe the pixels".

Visual phenomena in the real world are, AFAIK, continuous. So any digital representation of them involves discretization and approximation. Yes, you could encode a video or picture that, when rendered by a screen or printer will produce a visual stimulus similar to the real thing (or something that could be real, like the axe murder example). But the point is moot, because, since any digital representation can only approximate, you might as well use the easiest way (best tool, eg blender or ffmpeg) to accomplish the task of producing an image file that will produce the desired stimulus when rendered.

The following code (with omitted procedures implemented) will produce every 1920x1080x32 image that could ever exist (I think... hopefully you get the idea of the algorithm, regardless of whether it's correct or not).
I doubt there is enough storage on Earth (or maybe in the universe) to hold them all (2^(1920*1080*32) bits), but it will generate them, given sufficient hardware.

TylerH wrote:I doubt there is enough storage in existence (or maybe in the universe) to hold them all (2^(1920*1080*32) bits), but it will generate them, given sufficient hardware.

Hate to think of the render time too...

b.zaar wrote:

TylerH wrote:I doubt there is enough storage in existence (or maybe in the universe) to hold them all (2^(1920*1080*32) bits), but it will generate them, given sufficient hardware.

Hate to think of the render time too...

2^(1920*1080*32) = 2^66355200

A number that big would probably be better represented in graham notation. You could brute force about 30,000 AES encryptions in the amount of time it would take that program to finish.

So which one would finish first?

http://boingboing.net/2009/09/15/motor- ... to-se.html