image stills as a source for video: format doesn't matter?

[PharosSTL]

i have a quick question that at this point is more out of curiosity than necessity.

for my job i use SolidWorks, a 3D solid modeling suite, to generate parts and assemblies. you can then use SW to create animations and export these animations via a multitude of options. due to 64bit OS limitations, the codecs within SW are limited so i've been exporting the animations as image files -- one .bmp or .tga per frame.

at first i had a hard time with compression. i've gotten around that now and am satisfied with the results but again i am still curious about this issue... when you export .bmp files they are typically around 4.5Mb/frame. .tga files are a little smaller at about 2.2Mb per frame. now i know that this is mostly wasted space and that a decent .jpg compression would dramatically reduce file sizes without affecting the image quality too much.

so for a test run, i exported a 1-second clip from SW at 60fps as .bmp images. then i created copies of all those images and converted them to .jpg. the final result was that the .jpg files were in the neighborhood of 275 kb. obviously this is a dramatic decrease in file size.

both the .bmps and .jpgs were imported into virtualdub and two video files were created. uncompressed, raw video created from single frames.

61 .bmp frames * 4.5 Mb = ~275 Mb
61 .jpg frames * 275 kb = ~16.5 Mb

.avi file created from .bmp images = ~250 Mb
.avi file created from .jpg images = ~250 Mb
(.avi files have identical filesize)

now i think i know what's going on. i think that an uncompressed video of x duration and y framerate will result in a predetermined filesize. although i used lossy images as the basis of the .jpg video, they were combined in lossless or less efficient manner without any sort of compression.

so my real question is... is there a way to apply compression to the individual FRAMES, as images, prior to making the video? or does all compression have to come from within the video processor (vdub in my case)? because with our limited encoders available, i'm having a hard time getting a good mix of file size and video quality. on the other hand, these .jpgs each look great, and their filesize is miniscule.

realistically is there a way (video, or any animation/slideshow, flash .flv, etc.) that can theoretically just combine 60 .jpgs together and then play them back at 60fps?

thanks for letting me pick your brains for some insight...

n

[poisondeathray]

so my real question is... is there a way to apply compression to the individual FRAMES, as images, prior to making the video? or does all compression have to come from within the video processor (vdub in my case)? because with our limited encoders available, i'm having a hard time getting a good mix of file size and video quality. on the other hand, these .jpgs each look great, and their filesize is miniscule.

You can use .png if you want lossless compression for an image sequence , out of your 3d program . (vdub can do this too)

jpg compression is variable too (you usually have a quality slider if you want more or less quality, the tradeoff being filesize)

You can also apply lossy or lossless video compression , but you have to be careful with color space, and chroma subsampling formats (RGB, YUV, 4:2:2, 4:2:0) . Depending on the type of animation it might be less important, for other types of animation (those with fine lines, thin color borders), chroma subsampling becomes more important issue

realistically is there a way (video, or any animation/slideshow, flash .flv, etc.) that can theoretically just combine 60 .jpgs together and then play them back at 60fps?

There is, but it's player dependent and very situation dependent. e.g. you could just play them as an avs script - this obviously wouln't work for a web flash or html5 page, or a blu-ray player

So you have to be more specific on your exact requirements , what target devices, web, blu-ray, computer playback only ? what types of things hardware/software are the targets ?

What types of things are important in terms "quality" to you? Or is small filesize / compression more important ?.

For example, at 60FPS, it's unlikely the viewer will be able to see fine details in an animation , unless there is very little movement in the animation (in contrast, if you go frame by frame , or a much slower framerate e.g. 1FPS, then small details become more visible). If this is the case, then you can apply temporal video compression (interframe compression, instead of intraframe compression only) and reduce the filesize more

So - if you intend to use lossy video compression, you shouldn't use anything lossy beforehand (e.g. don't use jpg as the input files, instead use a png or bmp sequence) , because you incur avoidable generation lossess (each time you apply lossy compression, quality gets worse)

[PharosSTL]

thanks for all the input. let's see if i can't address most of this while still keeping it somewhat short!

.png is a moot point. SW only exports to .avi, .bmp, or .tga. i only converted the .bmps to .jpgs as an effort to perform my own compression on the individual stills as opposed to compressing the actual video.

the videos are intended for presentation, and there is some flexibility there as well. right now my intention is to push out four video files for each animation: 1600x1000, 800x500, 60fps, and 30 (29.97)fps. this is to give my boss flexibility in the application. the largest vids for presenting to investors, the smallest vids for uploading to our website. these videos aren't going to be played on anything over than a computer i don't have to worry about making these videos compatible with DVD or blu-ray or anything standardized like that.

i feel like these animations differ somewhat from a traditional movie, because the subject matter is 3D solid shaded geometry. i can't tell if this is a good thing or a bad thing! on one hand, lots of solid colors means large swaths of pixels with the same color --- easy compression? on the other hand, compression artifacts and hiccups are easier to notice because they can't be "hidden" like they could in a complex image with real-world lighting.

as for the framerate, this is set within solidworks. so higher framerates actually display finer detail in the animation. when i export at 60fps, solidworks generates 60 frames/second of animation and these are imported into vdub at 60fps. on the other hand, if i export from SW at 30fps, you only get half as many frames over the same period of time. due to the mechanical nature of these videos (parts rotating at 4,000RPM, etc.) the higher framerate is smoother, more fluid, and shows more detail

**although i'm not against exporting 60fps, and then using a linear blending to interpolate down to half the framerate, which is how i generate the 30fps vids.

**i will look into the temporal compression. i hadn't thought of this but it's a good idea. these videos do have a lot of still-time. seconds here and there where there is either very little or even no visible movement.

**as for "what i'm looking for" it's all subjective. anything smaller than 800x500 starts to look bad when viewed full screen, so that's my target for the resolution. as for the file size, it would be nice to have something to be able to stream from the web. however at this moment the smallest file size i've been able to generate that still manages to look decent is ~75 Mb. a little large for streaming over the web... this is using ffdshow's "MJPEG" codec in virtualdub64.

i think that's everything? gawl it's my fault for asking so many questions in a single post...

[poisondeathray]

as for the framerate, this is set within solidworks. so higher framerates actually display finer detail in the animation. when i export at 60fps, solidworks generates 60 frames/second of animation and these are imported into vdub at 60fps. on the other hand, if i export from SW at 30fps, you only get half as many frames over the same period of time. due to the mechanical nature of these videos (parts rotating at 4,000RPM, etc.) the higher framerate is smoother, more fluid, and shows more detail

Yes - definitely 60 fps will look better if the same time frame or animation is represented . That's what I would use for the big presentation. The point I was trying to get across (poorly) is the idea temporal compression.

At 60 FPS, each frame is represented on the display only 0.01667 seconds. Your average viewer won't notice small compression artifacts on individual frames because they pass by so quickly. But if you slowly examined each frame, frame by frame, you could more easily see defects. Another way of saying this, you can "hide" more artifacts at higher FPS playback. If that same animation is only represented by 1 frame, you 're essentially staring at a still picture like a slideshow. That' s the basic idea behind temporal compression - you code and store the differences between frames. Similarites between groups of frames cost very little to encode, because only the differences are encoded between the reference pictures. Typically you might get ~50% reduction in size with temporal compression, without noticeable quality loss.

this is using ffdshow's "MJPEG" codec in virtualdub64.

mjpeg is a poor choice for your purpose, because it's intra frame only (and cannot be streamed on web either)

I would use h.264 for video compression using x264 encoder . It's also compatible for flash / web . Until HEVC/ VP9 get more developed and more "usable", it still offers best usable compression today