Blender Quiz: Control Render Resolution Aspect Ratio And Output Formats

10 questions · exam conditions

0:00

Control Render Resolution Aspect Ratio And Output FormatsQuestion 1 of 10

A scene is configured with a resolution of $3840 \times 2160$ , a resolution percentage of $50\%$ , and a pixel aspect ratio of $2:1$ .

What raster dimensions will Blender save for each rendered image?

1920 \times 1080

pixels; pixel aspect changes the interpreted display shape, not the stored pixel count

3840 \times 2160

pixels; pixel aspect and percentage affect only playback display scaling

1920 \times 2160

pixels; the percentage applies only along the horizontal resolution axis

960 \times 1080

pixels; the pixel aspect ratio additionally divides the horizontal pixel count

← Back to quizzes

Blender Quiz

Blender Quiz: Control Render Resolution Aspect Ratio And Output Formats

Practice Control Render Resolution Aspect Ratio And Output Formats in Blender with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Control Render Resolution Aspect Ratio And Output Formats, giving you a quick way to practice the rules, question types, and explanations that matter most for Blender.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A scene is configured with a resolution of $3840 \times 2160$ , a resolution percentage of $50\%$ , and a pixel aspect ratio of $2:1$ .

What raster dimensions will Blender save for each rendered image?

$1920 \times 1080$ pixels; pixel aspect changes the interpreted display shape, not the stored pixel count (correct answer)
$3840 \times 2160$ pixels; pixel aspect and percentage affect only playback display scaling
$1920 \times 2160$ pixels; the percentage applies only along the horizontal resolution axis
$960 \times 1080$ pixels; the pixel aspect ratio additionally divides the horizontal pixel count

Explanation: When working through Blender render output questions, keep two settings clearly separated in your mind: resolution percentage and pixel aspect ratio, because they affect very different things. The resolution percentage scales the actual pixel dimensions that Blender renders and saves. Starting from

3840 \times 2160

, applying

50\%

gives you

1920 \times 1080

— those are the literal pixel counts written to disk. That confirms A as correct. The pixel aspect ratio, however, does not alter the stored pixel count. It tells software how to display each pixel — essentially stretching or squishing the image visually during playback or compositing. A

2:1

pixel aspect means each pixel is displayed twice as wide as it is tall, but Blender still saves exactly

1920 \times 1080

pixels to the file. Answer A captures this distinction precisely. B is wrong because it claims the resolution percentage doesn't affect saved dimensions — it absolutely does. The percentage directly scales the output pixel grid. C describes a fictional behavior where the percentage applies only horizontally, halving width while leaving height untouched. Blender's percentage scales both axes equally. D is the trickiest distractor: it conflates pixel aspect ratio with a divisor on the horizontal pixel count, giving

960 \times 1080

. This is the core misconception the question is testing — pixel aspect ratio never divides or multiplies stored pixels. As a study habit, always ask yourself: does this setting change stored pixels, or only display interpretation? Resolution percentage = stored pixels change. Pixel aspect ratio = display interpretation only.

Question 2

A lighting artist must deliver one file per frame containing the Combined image, Z depth, Normal, and several Light Group passes. The compositor must be able to access those passes separately without rendering again.

Which output format best satisfies this requirement?

PNG with RGBA enabled, because its alpha channel can contain all additional render passes
TIFF with $16$ -bit color, because higher bit depth automatically separates enabled render passes
Standard OpenEXR with RGBA, because four color channels represent every enabled View Layer pass
OpenEXR Multilayer, because it can store multiple named render passes and layers in each frame (correct answer)

Explanation: Whenever you see a question about delivering render passes to a compositor, focus on two requirements: multi-pass storage and named channel access — both must be satisfied without re-rendering. OpenEXR Multilayer is purpose-built for exactly this workflow. Each frame file can contain dozens of named passes — Combined, Z depth, Normal, Light Groups, and more — organized under labeled channels that any compositor (Nuke, Blender, DaVinci, etc.) can read and route individually. This makes D the correct answer: one file per frame, all passes intact, fully accessible downstream. A is wrong because PNG's alpha channel is a single transparency channel, not a container for arbitrary render data. Enabling RGBA gives you four channels total — nowhere near enough to store Z depth, normals, and multiple light groups simultaneously, let alone separately labeled. B is wrong because TIFF's bit depth controls precision (how finely color values are recorded), not capacity. A

16

-bit TIFF still stores only the channels a standard image format supports (RGB or RGBA). Bit depth and multi-pass storage are completely separate concepts — higher bit depth does not unlock pass separation. C is wrong because Standard OpenEXR with RGBA also gives you just four channels (R, G, B, A). It lacks the multi-layer architecture that lets you embed named passes. The "Standard" vs. "Multilayer" distinction in Blender's output settings is precisely the dividing line here. As a study tip: on Blender exam questions, "Multilayer" is the keyword that signals multi-pass compositing capability — any format without it cannot store named render passes in a single file.

Question 3

A PNG sequence covers frames $1$ through $100$ . Valid files for frames $1$ through $60$ already exist in the output folder. The Overwrite option is disabled, and the animation is rendered again using the same path.

What should Blender do when it encounters the existing sequence files?

Overwrite frames $1$ through $60$ , then render the remaining frames, because the PNG format does not respect the Overwrite setting
Abort the entire animation render at frame $1$ , because the first target filename already exists in the folder
Skip frames $1$ through $60$ and render only the missing frames from $61$ through $100$ (correct answer)
Render all frames again and append a numeric suffix to each filename that conflicts with an existing file

Explanation: When working with Blender's output settings, the Overwrite option is one of the most practical render controls to understand. It tells Blender what to do when a target output file already exists — and getting this wrong can mean hours of wasted render time. With Overwrite disabled, Blender treats existing files as already completed work. When it encounters a filename that already exists in the output folder, it simply moves on — skipping that frame entirely rather than re-rendering it. This makes option C correct: Blender skips frames

1

through

60

(which already exist) and renders only the missing frames

61

through

100

. This behavior is intentional and incredibly useful for resuming interrupted renders. Option A is wrong because the Overwrite setting applies universally across output formats, including PNG. There is no format-specific exception — PNG respects the setting just like any other image format. Option B describes behavior that doesn't exist in Blender. The renderer does not abort the entire job when it finds an existing file; it simply skips that individual frame and continues evaluating the rest of the sequence. An abort would defeat the purpose of the feature entirely. Option D is also incorrect. Blender does not append numeric suffixes or create duplicate files to avoid conflicts. That kind of behavior would quickly clutter your output folder and is not how the software handles collisions. A good study tip: think of the Overwrite toggle as a "resume render" switch. When disabled, Blender treats existing frames as done — perfect for picking up where a crashed or interrupted render left off.

Question 4

Two renders use identical resolution and color settings. Both are saved as PNG, but the second render uses a substantially higher PNG Compression value.

Assuming both files are written successfully, which result is most accurate?

The second image has fewer stored pixels because higher compression reduces the effective output resolution
The second image has reduced color precision because PNG compression discards subtle channel values
The second image gains a wider dynamic range because compression reallocates bits to brighter pixels
The second image takes longer to encode and can be smaller on disk, but its decoded pixel values are identical to the first (correct answer)

Explanation: When you see a question about PNG compression in Blender, the key concept to anchor yourself to is lossless vs. lossy compression. PNG uses lossless compression exclusively — meaning the compression algorithm reorganizes and encodes data more efficiently, but every single pixel value is perfectly preserved when the file is decoded. That's exactly what makes D correct. A higher PNG compression value tells Blender's encoder to work harder to find redundant patterns and pack them tightly, which typically produces a smaller file on disk. However, the trade-off is encoding time — more aggressive compression requires more computation. Critically, when you open either file, the decoded pixel values are bit-for-bit identical. No information is discarded. A is wrong because PNG compression has absolutely no effect on resolution. Every pixel from the render is stored regardless of the compression level — the output dimensions are determined by your render settings, not the file encoder. B describes lossy compression behavior, which applies to formats like JPEG. JPEG discards subtle color data to achieve smaller files. PNG never does this; it is fundamentally lossless by design, so channel values are never sacrificed. C is pure fabrication. Compression in any standard image format cannot "reallocate bits" to expand dynamic range. Dynamic range is determined by bit depth (e.g., 8-bit vs. 16-bit per channel), which is set independently of compression. Study tip: Remember the shorthand — PNG = lossless, JPEG = lossy. Any Blender question pairing PNG with "color loss" or "resolution loss" is always a trap. The only real trade-off with PNG compression is encode time versus file size.

Question 5

The output path is set to //renders/beauty_. The file format is PNG, File Extensions is enabled, and frame $23$ is rendered with Blender's standard four-digit frame padding.

Which filename will Blender generate for that frame?

beauty_23.png, using the frame number without leading zero padding
beauty_0023.png, using four-digit padding followed by the PNG extension (correct answer)
beauty_.0023.png, inserting a separator before the padded frame number
beauty_0023, using four-digit padding but omitting the enabled file extension

Explanation: When Blender saves a rendered frame, it builds the filename by appending the zero-padded frame number directly to whatever output path you've set, then attaches the format's extension if File Extensions is enabled. Understanding this assembly process is the key to these questions. With the output path //renders/beauty_, Blender appends frame

23

using its standard four-digit padding, producing beauty_0023, then appends .png because File Extensions is on — giving you beauty_0023.png, which is answer B. Here's why the other choices miss the mark. A ($beauty_23$.png) mistakes how Blender pads frame numbers — it always uses four digits by default, so frame

23

becomes 0023, not 23. Choosing A would mean Blender ignores its own padding convention. C (beauty_.0023.png) imagines Blender inserting an extra separator (.) between the path stem and the frame number, but Blender simply concatenates the frame digits directly onto the output path string — no automatic separator is added. D ( $beauty_0023$ ) gets the padding right but ignores the File Extensions toggle entirely. Since the question explicitly states File Extensions is enabled, omitting .png contradicts the setting — this choice is designed to trick you into forgetting that the toggle actually does something. A reliable study tip: remember that the output path is treated as a literal string prefix — Blender glues #### (four-digit frame) directly onto it, then adds the extension based on the toggle. If your path already ends with _, the result is _0023.png, with no extra characters inserted.

Question 6

A legacy preset renders $1440 \times 1080$ pixels with Pixel Aspect X $4$ and Y $3$ . It displays as $16:9$ , but a client now requires an actual raster of exactly $1920 \times 1080$ square pixels.

Which settings satisfy both the required raster dimensions and the required pixel shape?

Keep $1440 \times 1080$ and Pixel Aspect $4:3$ because its displayed shape is already $16:9$
Keep $1440 \times 1080$ but change Pixel Aspect to $1:1$ to make the pixels square
Set $1920 \times 1080$ and change Pixel Aspect to $1:1$ for square-pixel output (correct answer)
Set $1920 \times 1080$ but retain Pixel Aspect $4:3$ to preserve the legacy display shape

Explanation: Whenever you see a question about render output in Blender, you need to track two separate things: the raster dimensions (the actual pixel grid written to disk) and the pixel aspect ratio (the shape of each individual pixel). These are independent settings, and confusing them is the most common trap on questions like this. The client's requirement breaks into two clear constraints: an exact raster of

1920 \times 1080

pixels, and square pixels (meaning Pixel Aspect X and Y must both equal

1

, giving a ratio of

1:1

). Option C sets the Resolution X to

1920

and Y to

1080

, then sets Pixel Aspect to

1:1

— satisfying both constraints simultaneously. The display ratio becomes

\frac{1920}{1080} = \frac{16}{9}

, which is correct without any aspect-ratio tricks. Option A fails on both counts: the raster is still

1440 \times 1080

, not

1920 \times 1080

, and the pixels are non-square (

4:3

aspect). The fact that it displays as

16:9

is irrelevant — the client asked for a specific raster, not just a specific display shape. Option B corrects the pixel shape to

1:1

but leaves the raster at

1440 \times 1080

, so the file never contains the required

1920 \times 1080

pixel grid. Option D sets the right resolution but keeps the

4:3

pixel aspect, meaning every pixel is non-square — the output would appear stretched when played on a square-pixel display. A useful rule of thumb: raster size and pixel aspect ratio must each independently match the spec. Fixing one while ignoring the other always produces a wrong answer on Blender output questions.

Question 7

A workstation is likely to be interrupted during a long animation render. The final delivery will be an H.264 movie, but the intermediate render must be lossless, use standard dynamic range, and allow completed frames to survive an interruption.

Which output workflow most directly meets all of these requirements?

Render directly to an H.264 movie and restart the entire movie if encoding is interrupted
Render a PNG image sequence, then encode the completed sequence as H.264 afterward (correct answer)
Render a JPEG image sequence, then encode the completed sequence as H.264 afterward
Render one OpenEXR Multilayer file containing the complete animation, then rename it as an MP4

Explanation: When planning a long render in Blender, you need to think about three independent requirements simultaneously: crash recovery (interrupted frames must survive), intermediate quality (lossless and standard dynamic range), and final delivery format (H.264). The safest architecture separates the render step from the encode step. Rendering to a PNG image sequence satisfies all three requirements at once. PNG is lossless, uses standard dynamic range (8 or 16-bit integer), and — critically — saves each frame as its own file the moment it finishes. If your workstation crashes on frame 847, frames 1–846 are already sitting safely on disk. You then encode only the completed frames into H.264 as a separate pass. This is why B is correct. A fails the most important requirement: movie container formats like H.264 are written as a single continuous file. An interruption mid-render corrupts or loses the entire file, forcing a complete restart — exactly the disaster the question asks you to avoid. C uses a JPEG image sequence, which does survive interruptions frame-by-frame, but JPEG is a lossy format. Every frame is compressed with visible artifacts before it even reaches the H.264 encoder, violating the lossless intermediate requirement. D misunderstands how file formats work. OpenEXR Multilayer is a single file that stores all frames, so it offers no crash protection mid-render. Additionally, simply renaming a file does not re-encode it — an .exr renamed .mp4 is not a valid video file. Study tip: On render-workflow questions, scan for the phrase "survive an interruption" — it immediately points you toward image sequences over movie files, since sequences save progress frame-by-frame.

Question 8

A compositor needs a PNG image sequence in which the World background is transparent while foreground objects remain opaque. The current settings use an opaque Film background and PNG with Color set to RGB.

Which pair of changes is required to preserve the transparent background in the saved files?

Enable Film > Transparent and keep PNG Color set to RGB
Keep the Film opaque and change PNG Color from RGB to RGBA
Enable Film > Transparent and change PNG Color from RGB to RGBA (correct answer)
Enable transparent shadows and change PNG Color from RGB to BW

Explanation: Whenever you see a question about rendering transparent backgrounds in Blender, remember that transparency requires two independent settings to work together: one controlling what the renderer produces, and one controlling whether the output file stores that transparency data. The Film > Transparent setting (found in Render Properties) tells Blender's renderer to treat the World background as transparent instead of filling it with a solid color. Without this, every pixel in your render gets a background color baked in — there's simply no transparency to save, regardless of your file settings. Meanwhile, the PNG Color mode determines how pixel data is stored. RGB stores only red, green, and blue channels, so even if transparency exists in the render, it gets discarded. Switching to RGBA adds the alpha channel, which is what actually encodes which pixels are transparent vs. opaque. Both changes together are what option C describes, making it the correct answer. Option A fails because enabling Film > Transparent generates an alpha channel internally, but saving as RGB strips that alpha out — your PNG files will still have a solid background. Option B fails for the opposite reason: switching to RGBA does preserve an alpha channel if one exists, but since Film is still opaque, every pixel's alpha value will simply be 1.0 (fully opaque) — no transparency is ever generated in the first place. Option D introduces irrelevant settings — transparent shadows don't affect background transparency, and BW mode discards color entirely, producing grayscale images. A useful rule of thumb: Film > Transparent produces the alpha; RGBA saves it. You need both, every time.

Question 9

A render preset uses an X resolution of $2048$ , a Y resolution of $1152$ , and a resolution percentage of $75\%$ . The percentage must remain unchanged, but the final output must be exactly $1536 \times 1536$ pixels.

Which adjustment produces the required square output?

Change Y resolution to $2048$ while keeping X at $2048$ and percentage at $75\%$ (correct answer)
Change Y resolution to $1536$ while keeping X at $2048$ and percentage at $75\%$
Change X resolution to $1536$ and Y resolution to $2048$ while keeping $75\%$
Keep both resolution values unchanged and set the pixel aspect ratio to $1:1$

Explanation: When working with Blender's render resolution settings, remember that the final output size is always calculated as:

\text{Final} = \text{Base Resolution} \times \text{Percentage}

. The base resolution you set in the properties panel is not the output size — it's the starting value that gets scaled. Here, you need a final output of

1536 \times 1536

75\%

. That means you need to find the base resolution values that, when multiplied by

0.75

, yield

1536

. Working backwards:

1536 \div 0.75 = 2048

. So both X and Y base resolutions must be set to

2048

. That's exactly what answer A does — it keeps X at

2048

and changes Y from

1152

2048

, producing

2048 \times 0.75 = 1536

on both axes. B is tempting but wrong: setting Y to

1536

with

75\%

gives a final Y of

1536 \times 0.75 = 1152

, not

1536

. This confuses the base resolution with the desired output. C sets X to

1536

, which at

75\%

produces a final X of only

1152

, breaking the square requirement entirely. D misidentifies the problem — pixel aspect ratio controls the shape of individual pixels (used for non-square pixel formats like broadcast video), not the overall frame dimensions. Changing it won't resize the output to

1536 \times 1536

. A reliable study habit: always reverse-engineer base resolution from desired output by dividing by the percentage. If the final size is your target, the base must be

\text{target} \div \text{percentage}

Question 10

An output must use a fixed raster of $720 \times 576$ pixels but display at an aspect ratio of $4:3$ . The resolution dimensions cannot be changed.

Which pixel aspect ratio should be assigned to produce the required display aspect?

Pixel Aspect X $15$ and Y $16$ , making each pixel slightly taller than it is wide
Pixel Aspect X $16$ and Y $15$ , making each pixel slightly wider than it is tall (correct answer)
Pixel Aspect X $4$ and Y $3$ , directly matching the required overall display ratio
Pixel Aspect X $1$ and Y $1$ , because the raster dimensions already produce the required ratio

Explanation: When working with pixel aspect ratios in Blender, you need to understand that the display aspect ratio is determined by multiplying the pixel dimensions by the pixel shape. The formula is:

\text{Display AR} = \frac{\text{Width} \times \text{Pixel X}}{\text{Height} \times \text{Pixel Y}}

Here, your raster is

720 \times 576

. First, check what ratio that produces with square pixels:

720 \div 576 = 1.25

, which simplifies to

5:4

— not

4:3

. So square pixels won't work, and you need non-square pixels to compensate. To achieve a

4:3

display ratio, you need:

\frac{720 \times X}{576 \times Y} = \frac{4}{3}

Solving:

\frac{X}{Y} = \frac{4}{3} \times \frac{576}{720} = \frac{4 \times 576}{3 \times 720} = \frac{2304}{2160} = \frac{16}{15}

So Pixel Aspect X

= 16

, Y

= 15

, meaning each pixel is slightly wider than it is tall. That's answer B, the correct choice. A reverses the ratio (

15:16

), which would make pixels taller than wide and push the display toward a narrower aspect — the opposite of what's needed. C sets the pixel aspect to

4:3

directly, confusing the display ratio target with the pixel shape ratio; plugging those values in gives a distorted result. D assumes

720 \times 576

already equals

4:3

, but as shown, it actually produces

5:4

. A useful habit: always calculate the native raster ratio first before assuming square pixels will achieve the desired display aspect. On this exam,

720 \times 576

is a classic PAL resolution that almost always requires non-square pixels.