Gamma settings ?
21 messages in this thread
I know that the "GAMMA" topic maibe out of "fashion" on ASOFT but I need to
straighten out some "?" to "!". I think I got somewhat a grip on it but just
want to make sure I got It right! It's about the 4 settings of gamma in the
gamma dialoge. They are as follows :
Display gamma : 1.3 ( These values are added just to make )
Framebuffer gamma : 2.2 ( the discussion )
Input file gamma : 2.0
Output file gamma : 2.0
Questions :
1. If I render to the framebuffer and to to disk, wich of the Framebuffer or
Output file gamma is used when calculating gamma at 48bit color space? It
should be the Output file gamma! But what happens to the picture on screen?
Will it be gamma corrected at 24 bit space when displayd or the same as
outputfile gamma or not at all?
2. Is input file gamma used ONLY when the bitmap-format you load doesn't
have any gamma value? Is it then degammacorrected set by inputgamma and
then gamma corrected at 24bit accordingly to the frambuffer or
display gamma?
3. If I want to network render annimations with different output file gamma,
do I have to change the gamma value in the 3DS.SET file on every mashine?
For every entry!!!! It doesn't seam to be saved in the projectfile?! Maybe
wishlist <g>!
-M.E
Martin:
You are correct, gamma does not get saved in the project file. You need to
adjust it on every machine on the network.
I have found that the Framebuffer Gamma, the Input File Gamma, and the
Output File Gamma work best when all at the same setting, which
should be verified on the machine that takes the images out to tape.
We basically use two settings here, 2.2 for 'normal' projects, and 1.8 for the
'dark, spooky' look!
The display gamma should be set per machine.
Greg Pyros
Hi Greg:
>>You are correct, gamma does not get saved in the project file<<
Dan Spomer and I noticed that the gamma values were not being saved with the
.prj. The manual states that -all- system options are saved with .prj though.
We would change gamma, save, quit, reload 3DS, load .prj and the gamma was
different than when we saved. If we did not quit and just reloaded the same
.prj, the gamma was as saved….but….loading 3ds.prj,changing gamma,saving
and then loading the previous .prj resulted in the gamma being the same as the
3ds.prj file. So it appeared that changing 3ds.prj gamma changes all projects.
I can't explain it, but saw it happen.
Mike
Mike,
<<….but….loading 3ds.prj,changing gamma,saving and then loading the
previous .prj resulted in the gamma being the same as the 3ds.prj file. So it
appeared that changing 3ds.prj gamma changes all projects. I can't explain it,
but saw it happen. >>
What you saw happen is per the documentation. See ref man
installation guide pg 78, first paragraph.
jonas[adesk]
Thanks Jonas, I will read up on it. FYI, the printing problem that we have had
since October seems to go away with software "Print Cache". We are still
waiting to hear from QA regarding this problem. I still cannot print from 3DS
info boxes.
Mike
Jonas: One more time, after reading the manual, can I assume:
1.If 3ds.prj exists, opening 3DS automatically reads its gamma, and any project
opened during that session will take the gamma from 3ds.prj.
2. If 3ds.prj does not exist, Gamma is read from 3ds.set and effects all
projects opened during that session.
So it seems you can have 2 different ways of pre-setting gamma when
initializing.
Do you agree?
Thanks, as usual, for the great support (and babysitting <g>).
Mike
That's correct!
-JE
You've got it. Gamma can be a subtle characteristic. We figured you
didn't want your gamma changed by the simple act of loading a .prj
file (which you might have received from another person with totally
different system gamma settings). On the other hand, you want the
3ds.prj file to provide you with total customization. Thus, the
3ds.prj file carries system gamma settings, while all other .prj
files do not.
– Jack
Martin,
I'd just like to add Greg's comments and because of the values you put in your
table, that whatever values you use for your FRAMEBUFFER should also be matched
in INPUT and OUTPUT file, *unless* you want to change the input file gamma
value from its original value. (Which is very rare and probably should be done
independently before its used.
So if you're going to use:
Framebuffer gamma at 2.2 Input file gamma = 2.2 Output file gamma = 2.2
2.2 has less contrast than what many animators are accustom, which is why I
typically recommend 1.8 Light scenes can handle 2.2 Dark scenes may need to go
down to 1.2
Try using these values and then if this doesn't answer your questions come back
and re-ask for clarification.
-JE
<<Framebuffer gamma at 2.2 Input file gamma = 2.2 Output file gamma =
2.2>> I know that if i put all these settings to the same value I get
no problems with gamma, but if I have them all diffrent what will
happen? I was just wondering wich setting that do what and when? But
when writing all this down I think I'm beginning to explain to myself
what I didn't understand<g>!! But these are my own thoughts so I
wanted them acknoleged by someone else. So here goes again.
Fambuffer gamma:
Is used ONLY for viewing files on the frambuffer, and to get the right gamma
value to set into the output file gamma. When rendering only to the frambuffer
it will be gammacorrected to this value. Wich value is used when rendering
both to frambuffer and disk? Only outputfile gamma for both? Outputfile
gamma at 48bit and 24bit to the frambuffer? Or both in the 48bit colorspace
making the gamma calculation twice?
Input file gamma:
Is ONLY used for "degammyfying" pictures loaded without a gamma value inside
the file.
Output file gamma:
Is used for all images made within 3D Studio that will be saved to DISK.
-M.E
Ps I hope I got it right this time <g> Ds
Martin – Granted its a little confusing when you REALLY try to understand
what's going on, rather than relying on a preset formula.
When you render to the Framebuffer the gamma value specified for the
Framebuffer applies, ie you see the effect of the gamma correction on your
rendered framebuffer image. You seem to be very clear on this.
>>Which value is used when rendering both to framebuffer and disk? <<
The framebuffer gamma value is displayed and the output file gamma value goes
to disk. You can check this by rendering a frame buffer value different than
your output gamma value and saving the rendered image to disk. Then when you
"view last" you'll see the difference between the output file image and the
rendered image that you previously saw in the framebuffer. Which is why its a
good idea to keep these values the same.
The rendering in 48bit space is transparent to the user and gamma
correction is only applied once to the final rendered image.
Input file gamma takes the image in its standard state, whatever gamma
value it has. By applying the same gamma value as the framebuffer and
output file, you are keeping the input file gamma neutral, in other
words you're not changing its original gamma value. If the value is
not the same ie: its lower, then the picture becomes darker and if
the value is higher than it becomes brighter.
By adjusting the Input Gamma value higher than the ouput file gamma
you can doulbe gamma correct or gamma correct the input file image
depending on whether it was gamma corrected initially or not. I
prefer to gamma correct the image before I use it. Then when using
that image in rendering, by keeping the Input file gamma value the
same as the Framebuffer gamma and Output-file gamma, this maintains
the Input-file-image's gamma value I previously corrected the image
to. I also set the USE-TGA-GAMMA = OFF
Hope this clarify's gamma correction for you. Essentially the rule of
thumb is to keep the gamma values all the same. I don't rely on
Display gamma as I have a Framebuffer. For those will only a Display
you would want that to be consistent with Input and Output Gamma
values. And gamma correct for a specific image before hand if you
need that image gamma corrected. I find this less confusing.
John:
Good description! The only thing I'd add is that the display gamma may be
different from the others, because the display is looking at a linear computer
card and monitor, not an NTSC gamma-corrected image. They can be pretty
different from a framebuffer, and I don't think there is a pure relationship.
For example, on one of our stations with an AT-Vista and a Herc Graphite, I
find that if I go to the display at 1.8, it is equivalent to the Vista at 2.2.
Greg Pyros
Greg,
>> The only thing I'd add is that the display gamma may be different from the
others, because the display is looking at a linear computer card and monitor.
<<
Good point, and as I don't rely on my display for rendering I don't pay much
attention to its gamma setting. I would like to add that NTSC from the
framebuffer is a different beast than RGB from the framebuffer. In my earlier
post I was referring to the Framebuffer as the RGB output which is more similar
to the Display card ie: a linear computer card and monitor. Interesting point
about the display setting at 1.8 which is where I keep mine also.
-JE
Thanks for confirming my thoughts about the gamma settings, I think I
understand how it works. There is just some theoretical things left :-).
>The rendering in 48bit space is transparent to the user and gamma correction
>is only applied once to the final rendered image.
As I understand it the hole 48bit picture isn't held in memmory at
once. As this would take up MUSH memmory. There is a variable set in
the 3DS.SET file, "RENDER-BAND-WIDTH=10". I think, though I'm not
certain, that this is the number off lines held in memmory at one
time with 48bit, before gammacorrected to 24bit. If soo, is this
gammacorrection done twice if rendering to display and disk at the
same time? That is if you have different settings for display and
file gamma!
I know that these things don't matter mush if you set the values to
the same value, as you should. But then I have always been mush for
IF and WHY questions <g>!! The only way to learn and understand is to
ask question! Isn't it?<g>
-M.E
Martin,
>> As I understand it the whole 48bit picture isn't held in memory at once<<
Yes Martin it is. Which is one of the reasons you need more memory in
R3 than in R2. And it does gamma correction to whatever values you
specify for the framebuffer and the output-file. Now I understand
your double gamma correction concerns. I interpreted you statement to
mean that the same image was being double gamma corrected, which is
not the case, but the image held in memory is gamma corrected for
ouput at is goes to the framebuffer and then after that rendering is
complete the image is gamma corrected for file-output. Which is why
it is better to render to Null and the disk as it is slightly faster.
Another animation package I know, DGS works the way you suggest. It
doesn't provide for gamma correction during rendering but if you
render to the framebuffer that is where the image is being sent. This
conserves memory but does not provide framebuffer or display
independence. Maybe in the future 3DS will allow you to render
directly to the framebuffer thereby freeing up memory. The problem
is that this would also force an internal reworking for using Video
Post which relies on this internal space for compositing. And then
special drivers would have to be developed for each framebuffer to
take advantage of the Alpha channel. By not taking this approach 3DS
is able to accomadate a wider range of users, everyone from people
with an inexpensive 640x480x24 bit display to an expensive high end
Framebuffer like Truevision's DVR technology in its many forms.
At 37 I'm still asking "why?", (and I hope I always will) because as you
suggest, that's one of the ways to learn and understand. That way I don't put
myself in the box of having to know everything even if I don't. And I'm always
learning something new, which for me is one of the most enjoyable things in
life. <g>
Regards,
-JE
ME>> As I understand it the whole 48bit picture isn't held in memory at once<<
JE>>Yes Martin it is. Which is one of the reasons you need more memory in
than in R2.<<
Thanks, John! I have been going around thinking that the
"RENDER-BAND-WIDTH=10" had something to do with it!! Soo if it realy has the
hole image at 48 (or 64 bit for alpha), it will take up twice as mush
memmory for the output picture buffer as in R2. For a 1024×768 picture this
would mean 4.7 MB instead of 2.35 MB, allocated for the buffer. Thats nice
to know when making posters, as I usally do at 3000×2250, and it starts
taking up MUSH more memmory!
Thanks again for straighten out my question and putting me on the right
track again<g>!
<<And I'm always learning something new, which for me is one of the most
enjoyable things in life. <g>>>
Agree!!
-M.E
You're very welcome Martin, and if you ever get a chance to upload a smaller
version of your posters, I'd really enjoy checking them out.
-JE
<<upload a smaller version of your posters, I'd really enjoy checking them
out.>> I will!!
-M.E
Great! Let me know when you do.
-JE
I have just discoverd something NEW, to me atleast<g>!! The output- and
input-file gamma values present while making a network rendering IS SAVED
in the network process. The field order is also saved!? If one loads the .PRJ
file from the netque path the settings in the local 3DS.SET file still is used.
But when starting slave mode, the saved gammavalues are restored to the state
it was when making the netque process, overwriting the local 3DS.SET file
settings.
The fact that this works is great, I just didn't know about it <g>!!
I would be glad to have this confirmed by any at Yost Group to, so this
isn't the result of some strange circomstances at myplace!
-M.E
It's a feature.
– G