Render Output Format - Revision history

Standingpad: /* Recommendations */ Fix reference to Tom Scott video

2026-05-16T22:13:21Z

Recommendations: Fix reference to Tom Scott video

← Older revision		Revision as of 22:13, 16 May 2026
Line 3:		Line 3:
	== Recommendations ==		== Recommendations ==

	For the vast majority of cases, it is recommended to save the render output in an image based format, as the extra complexity of video formats<ref>~~Tom Scott on video compression:~~ https://youtu.be/r6Rp-uo6HmI</ref> can cause corruption issues in the middle of a render. In addition, memory issues during a render for animation can also cause individual frames to be corrupted with their output, which for single images is easier to fix with a simple re-render.		For the vast majority of cases, it is recommended to save the render output in an image based format, as the extra complexity of video formats<ref>[https://youtu.be/r6Rp-uo6HmI Tom Scott: Why Snow and Confetti Ruin YouTube Video Quality]</ref> can cause corruption issues in the middle of a render. In addition, memory issues during a render for animation can also cause individual frames to be corrupted with their output, which for single images is easier to fix with a simple re-render.

	=== Image Formats ===		=== Image Formats ===

Standingpad: Refer to Wikipedia for tone mapping

2026-05-16T07:06:14Z

Refer to Wikipedia for tone mapping

← Older revision		Revision as of 07:06, 16 May 2026
Line 7:		Line 7:
	=== Image Formats ===		=== Image Formats ===

	In terms of image formats, lossy compression is generally discouraged, as a large amount of information and quality is lost in the compression process. In cases where heavy post-processing is not needed, common formats include [[wikipedia:PNG\|PNG]] and [[wikipedia:TIFF\|TIFF]]. In cases where heavy post-processing is needed, [[wikipedia:OpenEXR\|EXR]] is recommended, as the extra information stored in each pixel allows for much more flexibility. It should be noted however that [[~~Tonemapper~~\|~~tonemapping~~]] isn't baked into EXR outputs, so ~~tonemapping~~ will need to be performed in any later programs used for post-processing. As EXRs store much more information compared to other formats, lossy compression algorithms such as DWAA can be used to reduce image sizes, without losing as much in quality compared to [[wikipedia:JPEG\|JPEG]].		In terms of image formats, lossy compression is generally discouraged, as a large amount of information and quality is lost in the compression process. In cases where heavy post-processing is not needed, common formats include [[wikipedia:PNG\|PNG]] and [[wikipedia:TIFF\|TIFF]]. In cases where heavy post-processing is needed, [[wikipedia:OpenEXR\|EXR]] is recommended, as the extra information stored in each pixel allows for much more flexibility. It should be noted however that [[wikipedia:Tone_mapping\|tone mapping]] isn't baked into EXR outputs, so tone mapping will need to be performed in any later programs used for post-processing. As EXRs store much more information compared to other formats, lossy compression algorithms such as DWAA can be used to reduce image sizes, without losing as much in quality compared to [[wikipedia:JPEG\|JPEG]].

	In situations where file sizes need to be reduced (such as posting on the internet), it's best to first output to a file format of a high quality (e.g. PNG, TIFF, EXR, etc.), then convert the high quality image to a lower quality image, or to a format with lossy compression and low file sizes (e.g. JPEG, [[wikipedia:WebP\|WebP]], [[wikipedia:JPEG_XL\|JPEG-XL]], etc.). The main benefit of this approach is being able to convert to multiple images of varying qualities from one, high quality source image, either for the purposes of experimentation or for having different qualities for different purposes (e.g. thumbnails, banners, profile pictures, etc.). In addition, for animation, having a high quality image sequence allows for more flexibility with the final video file, allowing for easily switching between different codecs (e.g. [[wikipedia:Advanced_Video_Coding\|H.264]], [[wikipedia:High_Efficiency_Video_Coding\|H.265/HEVC]], [[wikipedia:AV1\|AV1]], etc.), adjusting bitrate, etc.		In situations where file sizes need to be reduced (such as posting on the internet), it's best to first output to a file format of a high quality (e.g. PNG, TIFF, EXR, etc.), then convert the high quality image to a lower quality image, or to a format with lossy compression and low file sizes (e.g. JPEG, [[wikipedia:WebP\|WebP]], [[wikipedia:JPEG_XL\|JPEG-XL]], etc.). The main benefit of this approach is being able to convert to multiple images of varying qualities from one, high quality source image, either for the purposes of experimentation or for having different qualities for different purposes (e.g. thumbnails, banners, profile pictures, etc.). In addition, for animation, having a high quality image sequence allows for more flexibility with the final video file, allowing for easily switching between different codecs (e.g. [[wikipedia:Advanced_Video_Coding\|H.264]], [[wikipedia:High_Efficiency_Video_Coding\|H.265/HEVC]], [[wikipedia:AV1\|AV1]], etc.), adjusting bitrate, etc.

Standingpad: Add information on HDR output

2026-05-16T07:05:12Z

Add information on HDR output

← Older revision		Revision as of 07:05, 16 May 2026
Line 25:		Line 25:

	When encoding video, the [[wikipedia:Bit_rate\|bitrate]] must also be considered. Bitrate defines the amount of bits used for encoding video, generally on a per second basis. This is to some degree independent of resolution; for example, 4K video that is streamed over the internet often has a much lower bitrate than 4K video from UHD Blu-rays. A higher bitrate allows for more data can be present in the encoded video, but at the cost of increased file sizes; a lower bitrate by contrast allows for smaller file sizes, but at the cost of detail in the encoded video.		When encoding video, the [[wikipedia:Bit_rate\|bitrate]] must also be considered. Bitrate defines the amount of bits used for encoding video, generally on a per second basis. This is to some degree independent of resolution; for example, 4K video that is streamed over the internet often has a much lower bitrate than 4K video from UHD Blu-rays. A higher bitrate allows for more data can be present in the encoded video, but at the cost of increased file sizes; a lower bitrate by contrast allows for smaller file sizes, but at the cost of detail in the encoded video.

			=== HDR Output ===

			Certain formats are able to store HDR data which can then be viewed on a display capable of viewing HDR content. Often, a [[wikipedia:Transfer_functions_in_imaging\|transfer function]] needs be specified to dictate how the content should be displayed. Most programs give the option of either Hybrid log-gamma (HLG) and Perceptual Quantizer (PQ) as transfer functions.

			Hybrid log-gamma is a transfer function that is backwards compatible with [[wikipedia:Standard-dynamic-range_video\|SDR]], where the display output is scaled based on the capabilities of the display.<ref>[https://youtu.be/OF0FRxFBQnY?t=438 Christopher 3D: The New Blender 5.0 HDR Secret - HLG]</ref><ref>https://en.wikipedia.org/wiki/Hybrid_log%E2%80%93gamma</ref>.

			Perceptual quantizer is a transfer function where the display output is consistent across multiple displays. For example, if a pixel outputs <math>1000</math> nits, then it will be displayed as <math>1000</math> nits on all displays, regardless of their actual capability. This consistency however comes at the cost of backwards compatibility with SDR displays. Many video editors will expect imported HDR images to use the perceptual quantizer transfer function<ref>[https://youtu.be/OF0FRxFBQnY?t=461 Christopher 3D: The New Blender 5.0 HDR Secret - PQ]</ref><ref>https://en.wikipedia.org/wiki/Perceptual_quantizer</ref>.

Standingpad: Add information about bitrate

2025-09-26T21:20:10Z

Add information about bitrate

← Older revision		Revision as of 21:20, 26 September 2025
Line 23:		Line 23:

	In recent years, the AV1 codec has become more widely used, due to being more efficient with file sizes and not being under patents. However, hardware encoding/decoding for AV1 isn't as widely supported, being limited mainly to newer systems.		In recent years, the AV1 codec has become more widely used, due to being more efficient with file sizes and not being under patents. However, hardware encoding/decoding for AV1 isn't as widely supported, being limited mainly to newer systems.

			When encoding video, the [[wikipedia:Bit_rate\|bitrate]] must also be considered. Bitrate defines the amount of bits used for encoding video, generally on a per second basis. This is to some degree independent of resolution; for example, 4K video that is streamed over the internet often has a much lower bitrate than 4K video from UHD Blu-rays. A higher bitrate allows for more data can be present in the encoded video, but at the cost of increased file sizes; a lower bitrate by contrast allows for smaller file sizes, but at the cost of detail in the encoded video.

Standingpad: Add video codecs section to render output format page

2025-09-25T21:32:35Z

Add video codecs section to render output format page

@@ Line 4: / Line 4: @@
 For the vast majority of cases, it is recommended to save the render output in an image based format, as the extra complexity of video formats<ref>Tom Scott on video compression: https://youtu.be/r6Rp-uo6HmI</ref> can cause corruption issues in the middle of a render. In addition, memory issues during a render for animation can also cause individual frames to be corrupted with their output, which for single images is easier to fix with a simple re-render.
 In terms of image formats, lossy compression is generally discouraged, as a large amount of information and quality is lost in the compression process. In cases where heavy post-processing is not needed, common formats include [[wikipedia:PNG|PNG]] and [[wikipedia:TIFF|TIFF]]. In cases where heavy post-processing is needed, [[wikipedia:OpenEXR|EXR]] is recommended, as the extra information stored in each pixel allows for much more flexibility. It should be noted however that [[Tonemapper|tonemapping]] isn't baked into EXR outputs, so tonemapping will need to be performed in any later programs used for post-processing. As EXRs store much more information compared to other formats, lossy compression algorithms such as DWAA can be used to reduce image sizes, without losing as much in quality compared to [[wikipedia:JPEG|JPEG]].
 In situations where file sizes need to be reduced (such as posting on the internet), it's best to first output to a file format of a high quality (e.g. PNG, TIFF, EXR, etc.), then convert the high quality image to a lower quality image, or to a format with lossy compression and low file sizes (e.g. JPEG, [[wikipedia:WebP|WebP]], [[wikipedia:JPEG_XL|JPEG-XL]], etc.). The main benefit of this approach is being able to convert to multiple images of varying qualities from one, high quality source image, either for the purposes of experimentation or for having different qualities for different purposes (e.g. thumbnails, banners, profile pictures, etc.). In addition, for animation, having a high quality image sequence allows for more flexibility with the final video file, allowing for easily switching between different codecs (e.g. [[wikipedia:Advanced_Video_Coding|H.264]], [[wikipedia:High_Efficiency_Video_Coding|H.265/HEVC]], [[wikipedia:AV1|AV1]], etc.), adjusting bitrate, etc.

Standingpad: Expanded recommendations section for render output formats

2025-09-24T23:24:02Z

Expanded recommendations section for render output formats

← Older revision		Revision as of 23:24, 24 September 2025
Line 3:		Line 3:
	== Recommendations ==		== Recommendations ==

	For the vast majority of cases, it is recommended to save the render output in an image based format, as the extra complexity of video formats<ref>Tom Scott on ~~Video Compression~~: https://youtu.be/r6Rp-uo6HmI</ref> can cause corruption issues in the middle of a render. In addition, memory issues during a render for animation can also cause individual frames to be corrupted with their output, which for single images is easier to fix with a simple re-render.		For the vast majority of cases, it is recommended to save the render output in an image based format, as the extra complexity of video formats<ref>Tom Scott on video compression: https://youtu.be/r6Rp-uo6HmI</ref> can cause corruption issues in the middle of a render. In addition, memory issues during a render for animation can also cause individual frames to be corrupted with their output, which for single images is easier to fix with a simple re-render.

			In terms of image formats, lossy compression is generally discouraged, as a large amount of information and quality is lost in the compression process. In cases where heavy post-processing is not needed, common formats include [[wikipedia:PNG\|PNG]] and [[wikipedia:TIFF\|TIFF]]. In cases where heavy post-processing is needed, [[wikipedia:OpenEXR\|EXR]] is recommended, as the extra information stored in each pixel allows for much more flexibility. It should be noted however that [[Tonemapper\|tonemapping]] isn't baked into EXR outputs, so tonemapping will need to be performed in any later programs used for post-processing. As EXRs store much more information compared to other formats, lossy compression algorithms such as DWAA can be used to reduce image sizes, without losing as much in quality compared to [[wikipedia:JPEG\|JPEG]].

			In situations where file sizes need to be reduced (such as posting on the internet), it's best to first output to a file format of a high quality (e.g. PNG, TIFF, EXR, etc.), then convert the high quality image to a lower quality image, or to a format with lossy compression and low file sizes (e.g. JPEG, [[wikipedia:WebP\|WebP]], [[wikipedia:JPEG_XL\|JPEG-XL]], etc.). The main benefit of this approach is being able to convert to multiple images of varying qualities from one, high quality source image, either for the purposes of experimentation or for having different qualities for different purposes (e.g. thumbnails, banners, profile pictures, etc.). In addition, for animation, having a high quality image sequence allows for more flexibility with the final video file, allowing for easily switching between different codecs (e.g. [[wikipedia:Advanced_Video_Coding\|H.264]], [[wikipedia:High_Efficiency_Video_Coding\|H.265/HEVC]], [[wikipedia:AV1\|AV1]], etc.), adjusting bitrate, etc.

Standingpad: Create initial Render Output Format page

2025-09-23T22:15:01Z

Create initial Render Output Format page

New page

Render output formats refer to file formats used to store the final [[Render Output|render output]] of a scene. This can either be in an image format, or video format.

== Recommendations ==

For the vast majority of cases, it is recommended to save the render output in an image based format, as the extra complexity of video formats<ref>Tom Scott on Video Compression: https://youtu.be/r6Rp-uo6HmI</ref> can cause corruption issues in the middle of a render. In addition, memory issues during a render for animation can also cause individual frames to be corrupted with their output, which for single images is easier to fix with a simple re-render.