Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:00,120 --> 00:00:05,400
Before starting to explore the post-processing
chain, it is important to draw the distinction
2
00:00:05,400 --> 00:00:11,880
between the scene referred and display referred
formats. so imagine you have just rendered your
3
00:00:11,880 --> 00:00:17,880
shiny new lighting setup in Blender and what
you see on screen actually has two layers to it.
4
00:00:17,880 --> 00:00:25,200
a deeper layer that we cannot see directly on our
screens is the data of our render engine, of Cycles,
5
00:00:25,200 --> 00:00:32,460
the unbounded light intensity is stored in the
32-bit format and then the second layer is what
6
00:00:32,460 --> 00:00:39,120
get transferred to our display or we actually see
on screen. that is called a display referred image.
7
00:00:40,500 --> 00:00:44,700
to better get the difference between these
two types of image and how it all ties with
8
00:00:44,700 --> 00:00:52,080
the post-processing chain, let's first save our
image as PNG or jpeg or any other 8-bit format
9
00:00:52,080 --> 00:00:58,920
with 8-bit holding a display referred data in
this case, so let's go with any 8-bit format
10
00:00:58,920 --> 00:01:06,780
like jpeg, PNG, Tiff, by saving the image in one
of these formats we will effectively bake the
11
00:01:06,780 --> 00:01:12,540
color management within the image pixels, it
will be the depth of the deeper data layer,
12
00:01:12,540 --> 00:01:18,660
the layer that held all the high dynamic
range intensities of light in your scene.
13
00:01:19,920 --> 00:01:25,320
actually it's pretty easy to prove that there
is some range of intensities underneath what is
14
00:01:25,320 --> 00:01:31,680
displayed, let's open our color management tab
to get access to exposure slider, it will come
15
00:01:31,680 --> 00:01:37,380
in handy in just a moment, now if we sample the
hottest spot in our render probably generated
16
00:01:37,380 --> 00:01:43,380
by the sun lamp via right clicking on it you
will see that there are intensities there that
17
00:01:43,380 --> 00:01:51,780
go well beyond one, for example the red channel is
as bright as 35 units and these units are not the
18
00:01:51,780 --> 00:01:58,680
display brightnesses that go from black to white,
these values are the unbounded brightnesses of
19
00:01:58,680 --> 00:02:05,940
the actual 3D scene, technically it can go from
zero all the way to infinity and beyond while
20
00:02:05,940 --> 00:02:12,900
our miserable Rec 709 displays are limited to go
from 0 to 1 in terms of intensity and that's it.
21
00:02:14,880 --> 00:02:22,440
now watch the hot spot, it's a really hot bunch of
pixels indeed, now if we start killing the exposure
22
00:02:22,440 --> 00:02:28,800
notice that the hotspot is still hot! why is it
so?! :) because it had the higher intensities right
23
00:02:28,800 --> 00:02:35,220
of the start, the intensity that we have sampled
before and if we sample it now it won't change,
24
00:02:35,220 --> 00:02:43,260
the red channel will still peak around the 35
to 40 units depending on where you sample it.
25
00:02:44,640 --> 00:02:50,280
so even after the reduction of the exposure in
the color management tab, the super bright scene
26
00:02:50,280 --> 00:02:57,180
referred light values still result in super bright
pixels on display after it gets transferred to
27
00:02:57,180 --> 00:03:03,540
our display via the color management system.
the CM letters here stand for color managed.
28
00:03:04,740 --> 00:03:08,760
so that's why this part doesn't
want to get dimmed even when we
29
00:03:08,760 --> 00:03:14,520
reduce the exposure, because it holds an
enormous punch in the scene referred realm.
30
00:03:17,460 --> 00:03:23,520
all right! so what what would be the right way to
save the entire dynamic range of this image then?
31
00:03:24,060 --> 00:03:31,560
there is a special type of image format meant for
storing such data, the scene referred data, glorious
32
00:03:31,560 --> 00:03:40,800
open exr for example, this format can store 32-bit
data with floating point accuracy or half floating
33
00:03:40,800 --> 00:03:46,620
point accuracy if you want to save on the file
size, it has a bunch of very potent compression
34
00:03:46,620 --> 00:03:52,500
codecs that we won't go into right now, but the the
main thing about it (let's keep it short) is that
35
00:03:52,500 --> 00:03:59,100
it can save the whole range of the scene referred
unbounded image data or light data in other words.
36
00:04:00,480 --> 00:04:07,260
and you guessed it, we will need this 32-bit
image fidelity in post processing, if we're
37
00:04:07,260 --> 00:04:11,160
gonna save the file just like we
did and post process it afterwards.
38
00:04:13,200 --> 00:04:19,140
to drive it home let's compare 8-bit display
referral and 32-bit scene referred formats in
39
00:04:19,140 --> 00:04:25,620
Blender compositor and see how it all works. so
I'm gonna open the new blend file, toggle the
40
00:04:25,620 --> 00:04:33,120
compositor right away, N to remove the right
two shelf check Use Nodes, what else... maybe for
41
00:04:33,120 --> 00:04:39,000
convenience's sake I'll create two windows, the
bottom one will be the image editor where we will
42
00:04:39,000 --> 00:04:46,380
preview our compositing chain, now the resolution
should be set to 1920 by 1080 pixels just like our
43
00:04:46,380 --> 00:04:51,900
original scene, it's the best practice to make
sure these two things align perfectly, now Ctrl
44
00:04:51,900 --> 00:04:57,720
Shift clicking on the render layer to create the
viewer node and then opening the viewer node in
45
00:04:57,720 --> 00:05:04,620
the image editor and this is our basic setup for
post processing, now instead of using the render
46
00:05:04,620 --> 00:05:11,760
layers as if we have just rendered something, let's
actually load our 8-bit image via the image node.
47
00:05:13,200 --> 00:05:20,100
so here we have two of these guys, the PNG
and the exr, let's start with the PNG one, so I'm
48
00:05:20,100 --> 00:05:26,400
connecting its image output to the viewer and
you tell me what did go wrong with the image?
49
00:05:27,420 --> 00:05:32,940
can you see this dusty screen effect like the
image got flattened? that's because the filmic
50
00:05:32,940 --> 00:05:39,300
view transform was applied twice technically, first
we baked the display transform right into an 8-bit
51
00:05:39,300 --> 00:05:45,900
image, a PNG in our case and then we applied the
display transform for the second time in this
52
00:05:45,900 --> 00:05:52,080
new blender scene, hence the weird flattening of the
contrast, on top of that we have lost all the wide
53
00:05:52,080 --> 00:05:59,040
dynamic range on saving in the PNG format. now
the litmus test! :) the reduction of the exposure.
54
00:06:01,980 --> 00:06:08,340
remember we had the area of the higher intensities
that spanned across the wide dynamic range and
55
00:06:08,340 --> 00:06:14,400
went all the way to 35 and above? yeah, forget
about it, it was clipped to 1 on saving the
56
00:06:14,400 --> 00:06:21,240
PNG file, it was clipped to display. sadly for us
3D lighting artists the scene referred lighting
57
00:06:21,240 --> 00:06:29,040
data is no more. we technically can do nothing about
it and to make it even more sad it will definitely
58
00:06:29,040 --> 00:06:35,160
affect our post processing options as well. let's
demonstrate it by throwing in the glare node.
59
00:06:36,120 --> 00:06:41,760
the way the glare effect works in Blender is that
it detects the very hot scene referred pixels with
60
00:06:41,760 --> 00:06:49,920
the intensities of 5, 10, 15, you name it and then it
blooms these higher intensity pixels, there are no
61
00:06:49,920 --> 00:06:55,320
more such pixels there they were all trashed,
so there is no more glare as simple as that.
62
00:06:57,840 --> 00:07:05,160
thankfully we have also saved the 32-bit open exr
with the unbounded light values, the scene referred
63
00:07:05,160 --> 00:07:11,940
values, which is important, so let's see how it
behaves instead. let us switch our image to the EXR
64
00:07:12,540 --> 00:07:19,740
and obviously the first thing everyone gonna do
is sample the bright pixels and... woo! we've got our
65
00:07:19,740 --> 00:07:27,480
high intensities back :) [sings: hello brightness my
old frieeeend] ...it's good to see them back!
66
00:07:27,480 --> 00:07:32,880
you can sample any bright area to just
double check if everything is all right,
67
00:07:34,500 --> 00:07:40,380
so that is the result that corresponds 100%
to the Blender render that we made in the
68
00:07:40,380 --> 00:07:47,040
previous tutorial, that is the the wide range of
lighting values intact, we can prove it by our
69
00:07:47,040 --> 00:07:53,940
exposure litmus test, the super bright bunch
of pixels generated by the lens flare... it is
70
00:07:53,940 --> 00:08:00,480
still there. now technically this 32-bit image file
should hold all the intensities we need for post
71
00:08:00,480 --> 00:08:07,020
processing, the full image data intact and so we
can go to building our universal post processing
72
00:08:07,020 --> 00:08:12,240
chain, but first for the sake of completing our
little experiment let's drop in the glare node.
73
00:08:13,380 --> 00:08:20,640
back into compositor, Shift A, Filter, Glare. now it
should absolutely catch those outstanding scene
74
00:08:20,640 --> 00:08:27,660
referred RGB pixels that go above the threshold
of 1 in terms of their intensity and so that
75
00:08:27,660 --> 00:08:34,080
is the major difference between saving the image
before post-processing it in the 8-Bit format such
76
00:08:34,080 --> 00:08:42,720
as PNG, jpeg or Tiff or utilizing one of the scene
referred formats such as open exr which is 32-bit
77
00:08:42,720 --> 00:08:49,440
by default. the scene referred image formats
were created for the computer graphics work,
78
00:08:49,440 --> 00:08:55,740
for storing the light values required for post
processing, so that naturally should be our choice
79
00:08:55,740 --> 00:09:01,920
and incidentally to double down on this point
when we hit F12 to render stuff out in Blender
80
00:09:01,920 --> 00:09:08,640
we render it internally precisely in the 32-bit
scene referred format (just to clarify things).
81
00:09:10,980 --> 00:09:17,220
here I want to pause really quickly and talk about
the alternative backdrop preview options. some
82
00:09:17,220 --> 00:09:22,260
people like to preview the Blender compositor
output not in the separate window such as the
83
00:09:22,260 --> 00:09:26,820
image editor at the bottom of the screen
but right within the Blender compositor one.
84
00:09:27,720 --> 00:09:32,520
in order to see our stuff right there we
just need to check the backdrop button at
85
00:09:32,520 --> 00:09:38,400
the top of the UI then this little preview
can be resized with help of the V or alt V
86
00:09:38,400 --> 00:09:43,140
shortcuts or panned around while holding
Alt and using the middle mouse button,
87
00:09:44,340 --> 00:09:50,400
what we see in the backdrop is actually the output
of the viewer node, so if you don't see anything
88
00:09:50,400 --> 00:09:56,760
you just need to add the viewer first. if it feels
more convenient for you to preview the compositing
89
00:09:56,760 --> 00:10:03,540
chain right in this viewport, I respect your choice
obviously :) don't forget about the viewer though.
90
00:10:06,000 --> 00:10:10,680
my personal preference is quite fluid and
it depends on my mood and on the project,
91
00:10:10,680 --> 00:10:16,620
fluctuates quite a bit, but I think my current vibe
would dictate me to use the image editor instead.
92
00:10:17,760 --> 00:10:22,500
now technically nothing prevents us from jumping
straight into building the post-processing chain.
12845
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.