User:Clipka - Revision history

Clipka at 16:48, 5 October 2018

2018-10-05T16:48:24Z

Clipka at 15:29, 22 December 2010

2010-12-22T15:29:39Z

Clipka at 23:35, 20 December 2010

2010-12-20T23:35:33Z

Clipka at 17:44, 9 December 2010

2010-12-09T17:44:40Z

Clipka at 11:02, 31 August 2010

2010-08-31T11:02:34Z

Clipka at 14:07, 22 August 2010

2010-08-22T14:07:10Z

Clipka at 20:06, 4 November 2009

2009-11-04T20:06:07Z

Clipka: Replaced content with '(...)'

2009-11-04T20:04:58Z

Replaced content with '(...)'

Clipka at 19:31, 4 November 2009

2009-11-04T19:31:30Z

Clipka at 19:11, 4 November 2009

2009-11-04T19:11:28Z

@@ Line 3: / Line 3: @@
 * [[User:Clipka/IncludeHierarchy]]
 * [[User:Clipka/Development]]
 * [[User:Clipka/GammaHandling|POV-Ray documentation Gamma Handling section]]
 * [[Documentation:Tutorial_Section_3.3#Gamma_Handling]]
 * [[Documentation:Tutorial_Section_3.7#Radiosity]]

← Older revision		Revision as of 15:29, 22 December 2010
Line 5:		Line 5:
	* [[User:Clipka/GammaHandling\|POV-Ray documentation Gamma Handling section]]		* [[User:Clipka/GammaHandling\|POV-Ray documentation Gamma Handling section]]
	* [[Documentation:Tutorial_Section_3.3#Gamma_Handling]]		* [[Documentation:Tutorial_Section_3.3#Gamma_Handling]]
		+	* [[Documentation:Tutorial_Section_3.7#Radiosity]]

← Older revision		Revision as of 23:35, 20 December 2010
Line 4:		Line 4:
	* [[User:Clipka/Development]]		* [[User:Clipka/Development]]
	* [[User:Clipka/GammaHandling\|POV-Ray documentation Gamma Handling section]]		* [[User:Clipka/GammaHandling\|POV-Ray documentation Gamma Handling section]]
		+	* [[Documentation:Tutorial_Section_3.3#Gamma_Handling]]

← Older revision		Revision as of 17:44, 9 December 2010
Line 3:		Line 3:
	* [[User:Clipka/IncludeHierarchy]]		* [[User:Clipka/IncludeHierarchy]]
	* [[User:Clipka/Development]]		* [[User:Clipka/Development]]
		+	* [[User:Clipka/GammaHandling\|POV-Ray documentation Gamma Handling section]]

← Older revision		Revision as of 11:02, 31 August 2010
Line 2:		Line 2:
	* [[User:Clipka/Gamma]]		* [[User:Clipka/Gamma]]
	* [[User:Clipka/IncludeHierarchy]]		* [[User:Clipka/IncludeHierarchy]]
		+	* [[User:Clipka/Development]]

← Older revision		Revision as of 14:07, 22 August 2010
Line 1:		Line 1:
	Working on:		Working on:
	* [[User:Clipka/Gamma]]		* [[User:Clipka/Gamma]]
		+	* [[User:Clipka/IncludeHierarchy]]

← Older revision		Revision as of 20:06, 4 November 2009
Line 1:		Line 1:
−	~~(...)~~	+	Working on:
		+	* [[User:Clipka/Gamma]]

← Older revision		Revision as of 20:04, 4 November 2009
Line 1:		Line 1:
−	~~= Gamma =~~	+	(...)
−
−	~~== What is this Gamma Thing All About? ==~~
−
−	~~In short, the whole "gamma" issue is about nonlinearity in image processing, regarding how intermediate brightness levels between 0% and 100% are interpreted.~~
−
−	To let you take a first brief glimpse at the can of worms we're about to open: A standard 8-bit image file has pixel values ranging from 0 to 255, equivalent to 0% and 100% brightness respectively. So what brightness would you expect for a value of 128? Well, 50%, right? ''Wrong''. A meager 22% is usually closer to the mark. (Or 20%, or 25%, or whatever exactly your system happens to make of it.) Unless we're talking about ''perceptual'' brightness: A physical light intensity of 22% actually ''looks'' surprisingly bright, and an observer may percieve it as something around 45% in between black and white. Depending on ambient viewing conditions.
−
−	~~== Why Should I Care? ==~~
−
−	Even as a POV-Ray beginner, you'll possibly care about the general phenomenon: The 50% vs. 22% vs. 45% thing - pixel values and ''perceptual'' brightness vs. ''physical'' light intensity. These differences have two major implications for you:
−
−	* Colors you pick in Photoshop (or Gimp or whatever your favorite image processing software may be) will not seem to work in POV-Ray as expected; grey-ish colors will simply appear too bright, while more colorful ones will appear washed out, or even off hue (this is because the nonlinearity affects each color component individually).
−	* When trying to achieve a certain brightness level, you may have difficulties getting the level right at first attempt.
−
−	~~As an advanced POV-Ray user, you may also worry about different systems exhibiting more or less subtle differences in the nonlinearity:~~
−
−	* The same image file may display differently on a friend's computer. Or the new LCD you're about to buy. Or the machine you're running your overnight renders on. Or the computers of the jurors of that internet ray tracing competition you're taking part in. You probably want to make sure they can see the barely-lit creature lurking in your nighttime scene, or that your daytime scene doesn't look too washed-out on their displays. Presuming they have done their own gamma homework of course.
−	* You want to be sure that the scene you share across the internet renders on the recipient's computer just as it does on your own.
−
−	~~== So What Can I Do About Those Color Picking Issues? ==~~
−
−	~~When picking pixel values from Photoshop (or whatever you have), you can use the following formula to compute the color parameters to use in your POV-Ray scene file:~~
−
−	~~:<math>colorvalue=\left( \frac{pixelvalue}{255} \right)^{2.2}</math>~~
−
−	~~If you frequently pick colors, you may also want to define a macro to do the job:~~
−
−	~~#macro PickedRGB(R,G,B)~~
−	~~#local Red = pow(R/255, 2.2);~~
−	~~#local Green = pow(G/255, 2.2);~~
−	~~#local Blue = pow(B/255, 2.2);~~
−	~~rgb <Red,Green,Blue>~~
−	~~#end~~
−
−	~~#local MyColor = color PickedRGB(255,128,0);~~
−
−	If you generally feel more at home with defining colors by pixel values rather than physical brightness levels, you can use the same macro of course for all your colors, not just those you picked from some image-editing application.
−
−	~~== Why Does POV-Ray Not Do it The Photoshop Way? ==~~
−
−	With raytracing being essentially an attempt to simulate the ''physical'' interaction of light rays with object surfaces and media, it should come as no surprise that the math behind it is easiest (and fastest) when brightness levels are expressed as ''physical light intensity'', rather than ''perceptual'' brightness (which varies with viewing conditions anyway) or the more or less arbitrary concept of ''pixel values'' (~~which we'll go into detail later)~~. ~~To get realistic results at reasonable speed, a raytracing system ''must'' do virtually all its internal computations with physical light intensity~~.
−
−	~~Still, in theory this would not stop us from having the user specify all colors by pixel values, and automatically convert to physical light intensity just as the macro above does~~. ~~So why does POV-Ray not do it?~~
−
−	The answer lies in the power of the scene description language: You can do too much with colors in POV-Ray's SDL that it is practically imposible to come up with a watertight automatism of identifying which non-color value specified in a scene file will wind up being interpeted as a color nonetheless (and therefore would have to be subject to conversion), which color value will end up being interpreted as a non-color (and therefore would have to be exempt from conversion)~~, and whether some mathematical operation on colors should be performed in the pixel value domain or in the light intensity domain instead.~~
−
−	POV-Ray's philosophy therefore is to ''always'' presume colors to be expressed by linear light intensity values, and leave it up to the user to explicitly specify when and where conversions are to be applied.
−
−	~~== So What Can I Do About Those System-Dependent Differences? ==~~
−
−	~~In a nutshell, the answer is: Calibrate your system, and encourage others to do the same.~~

@@ Line 23: / Line 23: @@
 When picking pixel values from Photoshop (or whatever you have), you can use the following formula to compute the color parameters to use in your POV-Ray scene file:
-<math>colorvalue=\left( \frac{pixelvalue}{255} \right)^{2.2}</math>
+:<math>colorvalue=\left( \frac{pixelvalue}{255} \right)^{2.2}</math>
 If you frequently pick colors, you may also want to define a macro to do the job:

← Older revision		Revision as of 19:11, 4 November 2009
Line 1:		Line 1:
−	(~~My page~~.)	+	= Gamma =
		+
		+	== What is this Gamma Thing All About? ==
		+
		+	In short, the whole "gamma" issue is about nonlinearity in image processing, regarding how intermediate brightness levels between 0% and 100% are interpreted.
		+
		+	To let you take a first brief glimpse at the can of worms we're about to open: A standard 8-bit image file has pixel values ranging from 0 to 255, equivalent to 0% and 100% brightness respectively. So what brightness would you expect for a value of 128? Well, 50%, right? ''Wrong''. A meager 22% is usually closer to the mark. (Or 20%, or 25%, or whatever exactly your system happens to make of it.) Unless we're talking about ''perceptual'' brightness: A physical light intensity of 22% actually ''looks'' surprisingly bright, and an observer may percieve it as something around 45% in between black and white. Depending on ambient viewing conditions.
		+
		+	== Why Should I Care? ==
		+
		+	Even as a POV-Ray beginner, you'll possibly care about the general phenomenon: The 50% vs. 22% vs. 45% thing - pixel values and ''perceptual'' brightness vs. ''physical'' light intensity. These differences have two major implications for you:
		+
		+	* Colors you pick in Photoshop (or Gimp or whatever your favorite image processing software may be) will not seem to work in POV-Ray as expected; grey-ish colors will simply appear too bright, while more colorful ones will appear washed out, or even off hue (this is because the nonlinearity affects each color component individually).
		+	* When trying to achieve a certain brightness level, you may have difficulties getting the level right at first attempt.
		+
		+	As an advanced POV-Ray user, you may also worry about different systems exhibiting more or less subtle differences in the nonlinearity:
		+
		+	* The same image file may display differently on a friend's computer. Or the new LCD you're about to buy. Or the machine you're running your overnight renders on. Or the computers of the jurors of that internet ray tracing competition you're taking part in. You probably want to make sure they can see the barely-lit creature lurking in your nighttime scene, or that your daytime scene doesn't look too washed-out on their displays. Presuming they have done their own gamma homework of course.
		+	* You want to be sure that the scene you share across the internet renders on the recipient's computer just as it does on your own.
		+
		+	== So What Can I Do About Those Color Picking Issues? ==
		+
		+	When picking pixel values from Photoshop (or whatever you have), you can use the following formula to compute the color parameters to use in your POV-Ray scene file:
		+
		+	<math>colorvalue=\left( \frac{pixelvalue}{255} \right)^{2.2}</math>
		+
		+	If you frequently pick colors, you may also want to define a macro to do the job:
		+
		+	#macro PickedRGB(R,G,B)
		+	#local Red = pow(R/255, 2.2);
		+	#local Green = pow(G/255, 2.2);
		+	#local Blue = pow(B/255, 2.2);
		+	rgb <Red,Green,Blue>
		+	#end
		+
		+	#local MyColor = color PickedRGB(255,128,0);
		+
		+	If you generally feel more at home with defining colors by pixel values rather than physical brightness levels, you can use the same macro of course for all your colors, not just those you picked from some image-editing application.
		+
		+	== Why Does POV-Ray Not Do it The Photoshop Way? ==
		+
		+	With raytracing being essentially an attempt to simulate the ''physical'' interaction of light rays with object surfaces and media, it should come as no surprise that the math behind it is easiest (and fastest) when brightness levels are expressed as ''physical light intensity'', rather than ''perceptual'' brightness (which varies with viewing conditions anyway) or the more or less arbitrary concept of ''pixel values'' (which we'll go into detail later). To get realistic results at reasonable speed, a raytracing system ''must'' do virtually all its internal computations with physical light intensity.
		+
		+	Still, in theory this would not stop us from having the user specify all colors by pixel values, and automatically convert to physical light intensity just as the macro above does. So why does POV-Ray not do it?
		+
		+	The answer lies in the power of the scene description language: You can do too much with colors in POV-Ray's SDL that it is practically imposible to come up with a watertight automatism of identifying which non-color value specified in a scene file will wind up being interpeted as a color nonetheless (and therefore would have to be subject to conversion), which color value will end up being interpreted as a non-color (and therefore would have to be exempt from conversion), and whether some mathematical operation on colors should be performed in the pixel value domain or in the light intensity domain instead.
		+
		+	POV-Ray's philosophy therefore is to ''always'' presume colors to be expressed by linear light intensity values, and leave it up to the user to explicitly specify when and where conversions are to be applied.
		+
		+	== So What Can I Do About Those System-Dependent Differences? ==
		+
		+	In a nutshell, the answer is: Calibrate your system, and encourage others to do the same.