 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, and forgot to mention: The reflecting-sphere-on-checkered-plane shows
that something might be wrong with the output of POV-Ray 3.6, but it doesn't
explain why. It might be a good idea to explain what's going on with that
image and why it's wrong.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think this looks and feels very good.
While - to some extent - I agree with Warp, I believe the structure of the
text should remain as Clipka wrote it. After all, one can jump directly to
the practical part if one wants to.
To make that easier, I suggest to subdivide the text in 2 clear parts,
Theory and Practice, also mirrored (of course) in the Content, and increase
the number of code examples in the Practice part.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My own small 2-cents worth:
I kind of agree with Warp--the essay pretty much jumps right in with a rather
technical discussion. A GOOD one, of course--very well done!--but it needs a
short preamble, IMO, to get folks up to speed on what gamma is basically about
(as pertaining to *images*, which is what most of us first become concerned with
when doing CGI.) Perhaps something simple about how gamma basically bends the
color/grayscale values of an image, while leaving pure black and pure white
untouched. *Then* getting deeper into the technical aspects of CRT/LCD
reproduction, etc. I agree that part of the first paragraph, "...regarding how
intermediate brightness levels between 0% and 100% are interpreted," pretty much
says it all; but it doesn't quite grab me, or give an immediate picture in my
mind of how it basically affects images.
The best advice I ever heard about writing in general was, "Grab 'em right from
the start! Make it simple! Then they'll stick around for the details."
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, and I forgot to nit-pic :-p (My apologies if this isn't the right place
to do so.)
PERCIEVE is spelled PERCEIVE. I wouldn't normally mention it, but the word is
used throughout the text.
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
> Some brief history of why gamma correction exists in the first place
> (going all the way back to the invention of CRT) and where the name "gamma"
> comes from could be an interesting tidbit of information. This doesn't need
> to be long. One single paragraph should be enough.
Um... that information is in there already... so you got bored, hm? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot schrieb:
> I think this looks and feels very good.
Thank you (and all others so far) for the feedback.
> While - to some extent - I agree with Warp, I believe the structure of the
> text should remain as Clipka wrote it. After all, one can jump directly to
> the practical part if one wants to.
Yes, I'll probably stick to this structure, despite unexpectedly
numerous comments that suggest to change it.
While I do see the benefits of structuring it the other way round, there
is a pretty simple some reason why I didn't: The order I used is simply
my style of writing. I'd probably have a much harder time trying to get
it the other way round and still be happy with the text.
Once I hand over the text to the POV-Ray community, everyone who feels
up to it is free to propose a re-structured version of the text. No
problem there.
I don't think this is really needed though. For the average user, the
how-tos important to them probably boil down to (a) how to properly
calibrate the system and set the Display_Gamma option, and (b) the
advice to stay with POV-Ray's default settings and let the recently
implemented gamma handling automatisms do their job. (a) is best placed
(or at least linked to) in the installation section anyway, and (b) does
not need an elaborate tutorial. For any issues beyond that, I guess the
user will need at least some background information so that they can
assess which of the tips are applicable to their particular problem. And
if they already have that information, they can just skip to the how-tos
by virtue of the table of contents. I think the section titles are
talktive enough for that.
> To make that easier, I suggest to subdivide the text in 2 clear parts,
> Theory and Practice, also mirrored (of course) in the Content, and increase
> the number of code examples in the Practice part.
I guess I'd make that 3 parts: One "what is gamma all about" section
giving background information, one "why should I bother" section naming
some pitfalls, and one "how to" section describing how to deal with
those issues.
I'm reluctant to already put this subdivision into place though; the
current lower-level titles' typography makes me uneasy, them being much
bolder and prominent than normal section titles. Looks like they're
currently not intended to be used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Warp schrieb:
> > Some brief history of why gamma correction exists in the first place
> > (going all the way back to the invention of CRT) and where the name "gamma"
> > comes from could be an interesting tidbit of information. This doesn't need
> > to be long. One single paragraph should be enough.
> Um... that information is in there already... so you got bored, hm? ;-)
IIRC gamma correction started from the dawn of television and is related
to how a TV camera and a CRT works.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp schrieb:
>>> Some brief history of why gamma correction exists in the first place
>>> (going all the way back to the invention of CRT) and where the name "gamma"
>>> comes from could be an interesting tidbit of information. This doesn't need
>>> to be long. One single paragraph should be enough.
>
>> Um... that information is in there already... so you got bored, hm? ;-)
>
> IIRC gamma correction started from the dawn of television and is related
> to how a TV camera and a CRT works.
Ah, I get your point now.
No, I don't think I want to do a concise essay about gamma in image
processing in general. I'll leave that up to Wikipedia. I'm more in for
the facts pertaining to /digital/ image processing.
Yes, gamma pre-correction in TV broadcasting predates gamma
pre-correction in computers.
No, the one is not the reason for the other; rather, both share a common
reason: It simplifies driving the CRT.
I don't think the first CRTs used for computer displays were full TV
sets, as this would have required a HF modulator in the display adaptor
to drive the TV set's antenna input; more or less directly driving the
CRT would have required a much simpler hardware. So I guess the way TV
images were transmitted over the air was probably irrelevant for the
decision to gamma pre-correct computers' display output.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26.03.2010 22:04, clipka wrote:
> Comments appreciated.
Makes a good reading. And I do not agree with the reordering suggestions
but hey, it is a wiki article and everyone who wants to improve it can
do so.
What I do miss for the "Why should I care" section is the mentioning of
all the include files that are shipped with POV-Ray and have color
definitions within them (colors.inc, woods.inc, metals.inc ... ). All of
them do use gamma pre-corrected color definitions and are pretty useless
for 3.7 as they are now.
And the headline "Why Does POV-Ray Not Do It The Photoshop Way?" does
mostly show that you do not have a good idea of what (contemporary
versions) of P'shop are doing as most operations there are internally
done in linear color space and it is also fairly easy to setup the
P'shop color picker to show linear color values and not perceptual ones.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.03.2010 11:28, schrieb Ive:
> Makes a good reading. And I do not agree with the reordering suggestions
> but hey, it is a wiki article and everyone who wants to improve it can
> do so.
Yes. Well, at least as soon as the page moves from my own personal space
to some more official location.
> What I do miss for the "Why should I care" section is the mentioning of
> all the include files that are shipped with POV-Ray and have color
> definitions within them (colors.inc, woods.inc, metals.inc ... ). All of
> them do use gamma pre-corrected color definitions and are pretty useless
> for 3.7 as they are now.
That's a good point.
However, I think the proper approach for those would be to fix them by
virtue of an "#if (version >= 3.7)" statement (or, maybe even better
yet, pre-definition of macros as suggested by the article).
(I think the materials need rework anyway, to allow for better
interoperability with radiosity.)
Still, yes, even then the article should possibly mention the topic of
legacy scenes in general.
> And the headline "Why Does POV-Ray Not Do It The Photoshop Way?" does
> mostly show that you do not have a good idea of what (contemporary
> versions) of P'shop are doing as most operations there are internally
> done in linear color space and it is also fairly easy to setup the
> P'shop color picker to show linear color values and not perceptual ones.
With "The Photoshop Way" I intended to refer to what you get when you
use the color picking tool of image editing software in general (taking
Photoshop just as a popular example) - with gamma pre-corrected values
probably still being the default (I still have an older value of
Photoshop, so I might be wrong there). And as the internals are hidden
from the casual user anyway, I don't think many users would associate
that title with those inner workings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
