Hello,
I’m new with blender and I was wondering which procedure is the best between rendering in PNG then running h264 saving as .mp4 or rendering directly in h264/mp4 video?
Depending on how big your project is, typically you want to render image sequences then bring them in to a compositor/video editor (or back into blender) and compile them into a final video file format.
Sometimes I don’t bother, if it’s such a small project, I just work with .mp4 files. But it’s nice working with image sequences for reworking things, because you can just re-render a section of images if you need to, or adjust part of your project.
Or worse…blender crashes halfway through and your video file is a bust, in which case rendering an image sequence can save you from migraines.
I like using targa or tif files (sometimes jpg). Targa and more especially tif are uncompressed (png is good for saving space on your hard drive) and can be good for saving more color for post production.
If losing your mp4 video due to crash or render errors in frames has small time cost, you can render directly to mp4. If any error takes considerable time to re-render, render into image sequence first and assemble the video from sequence.
Depending on what you are rendering you can live with 8bit precision formats like jpg or png (meaning all values clip at 1.0). If you need to preserve all intensity values (whole dynamic range), use exr format. Exr has compression, high bit depth (16 or 32 depending on settings) and high dynamic range. Tiffs and targa images have no advantage over exr whatsoever because they are large and clip values at 1.0.
@kesonmis here is a question maybe you can answer. Ok I save EXRs in a file, 16 bit, for dynamic range but then H.264 is going to stomp all over it as it would PNGs. Will EXRs be able to retain more dynamic range then PNGs when converting to video.
Or, even is there a way to make sure they retain more dynamic range after being converted to H.264. By the way I said 16bit because every tutorial I’ve seen suggest clicking ‘Float (Half)’ This loss of dynamic range is killing me. I know we have to accept a little but what I’ve been seeing is ridiculous. Any help is appreciated.
AFAIK (someone correct me if I’m wrong) no video format supports full range. EXR is useful for textures (especially normal textures), or intermediate format for post-processing.
@theoldghost when you convert to video, your maximum end quality will depend on video compression logic and settings. If your chosen codec is more capable than png, for example has support for higher bit depth (prores etc) then you will benefit from using exr-s. For ordinary h264, there is nothing to gain in video. But exr-s give you the ability to do highlight compression, grading or tonemapping before converting to video. With png-s or other 8bit or 16bit integer formats you lose most of these options due to data loss when saving render buffer to raster file.
Videos support high dynamic range with different Log encodings. To make good use of logarithmic compression you need video codec that can save at least 10 bits per channel. Like prores, dnxhd, cineform etc. But unless you have a HDR monitor the dynamic range you are able to see is still clipped, this time by monitors maximum brightness and contrast. Only way to visualize a scene with high dynamic range is to nonlinearly remap it (compress highlights) for LDR output device. This ofcourse looses the real linearity and dynamic range in image data, but at least gives you an image that looks nice and has no objectionable hard clipping.
@ovnuniarchos the term “full range” can be confusing when talking about video and dynamic range. Full range means that there is no headroom and footroom in video data. The opposite is so called “legal range” which for rec709 is between values 16-235 in 8bit storage. Code values below and above the legal range are reserved for different technical purposes. Full range is 0-255( or 0.0-1.0 when talking about normalized values). For 32 or 16 bit float per channel image data the full range is the bounded by min and max values of float number, which for any practical use is way beyond “high enough”.
Nice note. I was referring, of course, to a range outside 0.0-1.0.
Many thanks although I’m none to enthused about the truth. Damn it! : )