 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I'm looking for a proper way to convert an HDR image into a function and
then back into a pigment.
The problem:
HDR images, when used as functions, produce color banding due to
clipped (wrapped) color values. This is the typical behavior of
functions, and should be expected.
My solution:
Divide the image function by 255 and multiply each channel's color by 255:
#declare F_IMG =
function{
pigment{
image_map{ hdr "some_img.hdr" }
}
}
average
pigment_map{
[1
function{ F_IMG(x,y,0).x/255 }
color_map{[0 rgb 0][1 rgb x*255*3]}
]
[1
function{ F_IMG(x,y,0).y/255 }
color_map{[0 rgb 0][1 rgb y*255*3]}
]
[1
function{ F_IMG(x,y,0).z/255 }
color_map{[0 rgb 0][1 rgb z*255*3]}
]
}
I have constrasted the result against a PNG image using a reflective
sphere, and also with with my lb7b file for adding glare to images. This
solution seems to preserve the original range and intensity of the HDR
image.
So my question is this: does this method seem alright to you? Is there a
better way? Is my math faulty?
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.01.2011 20:01, schrieb stbenge:
> Hello,
>
> I'm looking for a proper way to convert an HDR image into a function and
> then back into a pigment.
>
> The problem:
>
> HDR images, when used as functions, produce color banding due to clipped
> (wrapped) color values. This is the typical behavior of functions, and
> should be expected.
Ahh!!! Now I get it. It is not the function itself, it is the range of
the color_map that limits to the 0..1 range. Of course. So Jaimes min()
makes perfectly sense and your solution overcomes this limitation.
> My solution:
>
> Divide the image function by 255 and multiply each channel's color by 255:
The only issue: why 255? Using the 8bit byte range is a completely
random choice and I've seen much higher light intensities within HDR
image files. Given that OpenEXR uses 16bit floats (and Radiance
effectively also) and POV-Ray internal 32bit floats you can safely use a
value of e.g. 10000 without loosing precession.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hello,
>
> I'm looking for a proper way to convert an HDR image into a function and
> then back into a pigment.
>
> The problem:
>
> HDR images, when used as functions, produce color banding due to clipped
> (wrapped) color values. This is the typical behavior of functions, and
> should be expected.
>
> My solution:
>
> Divide the image function by 255 and multiply each channel's color by 255:
>
> #declare F_IMG =
> function{
> pigment{
> image_map{ hdr "some_img.hdr" }
> }
> }
> average
> pigment_map{
> [1
> function{ F_IMG(x,y,0).x/255 }
> color_map{[0 rgb 0][1 rgb x*255*3]}
> ]
> [1
> function{ F_IMG(x,y,0).y/255 }
> color_map{[0 rgb 0][1 rgb y*255*3]}
> ]
> [1
> function{ F_IMG(x,y,0).z/255 }
> color_map{[0 rgb 0][1 rgb z*255*3]}
> ]
> }
>
> I have constrasted the result against a PNG image using a reflective
> sphere, and also with with my lb7b file for adding glare to images. This
> solution seems to preserve the original range and intensity of the HDR
> image.
>
> So my question is this: does this method seem alright to you? Is there a
> better way? Is my math faulty?
>
> Sam
A factor of only 255 seems like very small, given that you can easily
find HDR images with a range of 50 000:1 and more.
If the Sun does show in the image and you have dark details in deep
shadows, the range can easily shoot past 1 million to 1.
Alain
Post a reply to this message
|
|
| |
| |
|
|
From: Jaime Vives Piqueres
Subject: Re: HDR images as functions: is this right?
Date: 27 Jan 2011 14:52:36
Message: <4d41cd04$1@news.povray.org>
|
|
|
| |
| |
|
|
> So my question is this: does this method seem alright to you? Is there a
> better way? Is my math faulty?
I don't know, but it's working pretty well for my light maps...
As you can read on the prior thread, Ive slapped my face again and
thanks to it I've discovered the OpenEXR output. It's working perfectly
to generate the light maps with alpha, but when using it back into the
texture via functions, I was getting a sort of "solarize" effect. Then I
read your post and realized this was the problem... thanks! Now I can
finish my baking tutorial! :)
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/27/2011 11:33 AM, Ive wrote:
> Am 27.01.2011 20:01, schrieb stbenge:
>> HDR images, when used as functions, produce color banding due to clipped
>> (wrapped) color values. This is the typical behavior of functions, and
>> should be expected.
>
> Ahh!!! Now I get it. It is not the function itself, it is the range of
> the color_map that limits to the 0..1 range. Of course. So Jaimes min()
> makes perfectly sense and your solution overcomes this limitation.
Yeah, it really had me stumped for a while :) I too tried min(), but
that just clamps the intensities... you might as well be using a PNG or
TGA image.
>> My solution:
>>
>> Divide the image function by 255 and multiply each channel's color by
>> 255:
>
> The only issue: why 255? Using the 8bit byte range is a completely
> random choice and I've seen much higher light intensities within HDR
> image files. Given that OpenEXR uses 16bit floats (and Radiance
> effectively also) and POV-Ray internal 32bit floats you can safely use a
> value of e.g. 10000 without loosing precession.
I'll admit that I guessed the range of values an HDR image can hold. I'd
like to find the maximum possible value so I can update Rune's
illusion.inc to support HDR images to the fullest extent.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/27/2011 11:47 AM, Alain wrote:
> A factor of only 255 seems like very small, given that you can easily
> find HDR images with a range of 50 000:1 and more.
> If the Sun does show in the image and you have dark details in deep
> shadows, the range can easily shoot past 1 million to 1.
So, what would be a safe value to use? I heard that HDR images support
32 bits for each color channel. So a value of 4,294,967,295 would work,
right?
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.01.2011 21:20, schrieb stbenge:
> On 1/27/2011 11:47 AM, Alain wrote:
>> A factor of only 255 seems like very small, given that you can easily
>> find HDR images with a range of 50 000:1 and more.
>> If the Sun does show in the image and you have dark details in deep
>> shadows, the range can easily shoot past 1 million to 1.
>
> So, what would be a safe value to use? I heard that HDR images support
> 32 bits for each color channel.
Err, OpenEXR and Radiance do use a 16bit *floating point*
representation. There is also TIFF that would support up to 32bit float
HDR images (and more!) but this is currently not supported by POV-Ray.
The problem is: to say what maximum is possible is not so simple. E.g.
you can represent light intensity of 50000:1 but cannot represent at the
same time details within dark regions with enough precision.
So a value of 4,294,967,295 would work,
> right?
No!!!
My suggestion of using 10000 is a kind of educated guess (to find the
exact value one had to look up how many bits are used for mantissa and
exponent within the 16 bit (half) floating point format as used by
OpenEXR in compare to the 32bit float format to find out what maximum
value can be used without starting to loose precision.
But this would still not mean that you can cover high dynamic ranges
like 50000:1 AND preserve precision! Thats the kind of nature of
floating points ;)
So sorry, there is no value that will work in all cases until you
examine the image itself and use the maximum that is used there.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 1/27/2011 11:47 AM, Alain wrote:
>> A factor of only 255 seems like very small, given that you can easily
>> find HDR images with a range of 50 000:1 and more.
>> If the Sun does show in the image and you have dark details in deep
>> shadows, the range can easily shoot past 1 million to 1.
>
> So, what would be a safe value to use? I heard that HDR images support
> 32 bits for each color channel. So a value of 4,294,967,295 would work,
> right?
>
> Sam
Maybe yes, maybe no.
It all depends on the actual range of the image you use and what amount
of precision loss you are willing to accept.
If the image have some extremely bright areas and you are not to
concerned about loosing precision from the darkest regions, dividing by
1000000 can be correct/acceptable. In this case, you may even need to do
some clipping.
If your actual range is smaller, with some subtile darker details, then
your 255, or less, can be enough.
If your high range is from a night scene where everything is dark, it
could be an idea to actualy multiply your values...
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/27/2011 1:03 PM, Ive wrote:
> Am 27.01.2011 21:20, schrieb stbenge:
>> So, what would be a safe value to use? I heard that HDR images support
>> 32 bits for each color channel.
>
> Err, OpenEXR and Radiance do use a 16bit *floating point*
> representation. There is also TIFF that would support up to 32bit float
> HDR images (and more!) but this is currently not supported by POV-Ray.
Well, in the case of Rune's illusion.inc, I /could/ implement different
default values for both OpenEXR and HDR...
> The problem is: to say what maximum is possible is not so simple. E.g.
> you can represent light intensity of 50000:1 but cannot represent at the
> same time details within dark regions with enough precision.
Ack, I didn't think about that :(
> So a value of 4,294,967,295 would work,
>> right?
>
> No!!!
>
> My suggestion of using 10000 is a kind of educated guess (to find the
> exact value one had to look up how many bits are used for mantissa and
> exponent within the 16 bit (half) floating point format as used by
> OpenEXR in compare to the 32bit float format to find out what maximum
> value can be used without starting to loose precision.
I think that might be a little beyond my capabilities ATM, but could it
be done in-POV without testing every single pixel?
> But this would still not mean that you can cover high dynamic ranges
> like 50000:1 AND preserve precision! Thats the kind of nature of
> floating points ;)
Can I at least assume 10000 would be a visually lossless value under
most circumstances?
> So sorry, there is no value that will work in all cases until you
> examine the image itself and use the maximum that is used there.
OK, so if a person *knows* what the brightest region in their scene is,
can a good value be derived from that knowledge? Especially if the
bright spots are below 10000?
This subject is more complex than I thought it was :S
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/27/2011 2:02 PM, Alain wrote:
> If your actual range is smaller, with some subtile darker details, then
> your 255, or less, can be enough.
How many people actually design scenes with light_sources or ambient
textures over 255? The main reason I am concerned is so I can update
Rune's illusion.inc which relies on images generated with POV...
> If your high range is from a night scene where everything is dark, it
> could be an idea to actualy multiply your values...
I'm really hoping to develop some "one size fits all" default values,
and let people worry about adjusting things only when it's absolutely
necessary.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
