 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So I scanned some real objects with two colors from two different angles to
produce an image that should more or less be a normal map. I'm wondering
if anyone knows of a quick/easy way to convert these images into height
fields. I think I could run it through some 4-dimensional derivative to
get something right, but I'm not positive.
with the y-axis being straight up, I have a red light coming from the x
direction and a green light from the z. My vectors are <red,green> with
values from 0-255 with <128,128> being straight up, <255,128> pointing to
positive x, and <128,255> pointing to positive z.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<Mienai> wrote in message
news:web.44166001d29a596193db03e80@news.povray.org...
> So I scanned some real objects with two colors from two different angles
> to
> produce an image that should more or less be a normal map. I'm wondering
> if anyone knows of a quick/easy way to convert these images into height
> fields. I think I could run it through some 4-dimensional derivative to
> get something right, but I'm not positive.
>
> with the y-axis being straight up, I have a red light coming from the x
> direction and a green light from the z. My vectors are <red,green> with
> values from 0-255 with <128,128> being straight up, <255,128> pointing to
> positive x, and <128,255> pointing to positive z.
>
Hi Mienai,
I think there are a few problems with this approach.
One biggy is that the images won't contain some of the information you would
need in order to create a height field - In particular the height. You would
need to know the distance of a point from the camera, which the colour
information in the images doesn't give you.
With the exception of certain shapes the colour information doesn't give you
all of the normal information either, because a colour of <200,200> could be
pointing slightly up or slightly down.
Even if you introduced a third colour and could get good approximate normal
information you would have to make some quite unreliable assumptions about
the contours and smoothness of the surface to attempt to derive positional
information from that. For example, it would still be possible to have a
step change in the surface height that is inperceptible in the image.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnect comnospam> wrote:
> <Mienai> wrote in message
> news:web.44166001d29a596193db03e80@news.povray.org...
> > So I scanned some real objects with two colors from two different angles
> > to
> > produce an image that should more or less be a normal map. I'm wondering
> > if anyone knows of a quick/easy way to convert these images into height
> > fields. I think I could run it through some 4-dimensional derivative to
> > get something right, but I'm not positive.
> >
> > with the y-axis being straight up, I have a red light coming from the x
> > direction and a green light from the z. My vectors are <red,green> with
> > values from 0-255 with <128,128> being straight up, <255,128> pointing to
> > positive x, and <128,255> pointing to positive z.
> >
>
> Hi Mienai,
>
> I think there are a few problems with this approach.
>
> One biggy is that the images won't contain some of the information you would
> need in order to create a height field - In particular the height. You would
> need to know the distance of a point from the camera, which the colour
> information in the images doesn't give you.
> With the exception of certain shapes the colour information doesn't give you
> all of the normal information either, because a colour of <200,200> could be
> pointing slightly up or slightly down.
>
> Even if you introduced a third colour and could get good approximate normal
> information you would have to make some quite unreliable assumptions about
> the contours and smoothness of the surface to attempt to derive positional
> information from that. For example, it would still be possible to have a
> step change in the surface height that is inperceptible in the image.
>
> Regards,
> Chris B.
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> Hi Mienai,
>
> I think there are a few problems with this approach.
>
> One biggy is that the images won't contain some of the information you would
> need in order to create a height field - In particular the height. You would
> need to know the distance of a point from the camera, which the colour
> information in the images doesn't give you.
> With the exception of certain shapes the colour information doesn't give you
> all of the normal information either, because a colour of <200,200> could be
> pointing slightly up or slightly down.
>
> Even if you introduced a third colour and could get good approximate normal
> information you would have to make some quite unreliable assumptions about
> the contours and smoothness of the surface to attempt to derive positional
> information from that. For example, it would still be possible to have a
> step change in the surface height that is inperceptible in the image.
>
> Regards,
> Chris B.
The way I was thinking of it was that the normal is providing the delta in
height (slope) that's why I was thinking that I could just run the image
through a derivative to get an approximate height based of some +c value
(basic calculus, right?). While I agree that there are going to be some
inconsistancies (specially on vertical slopes) I still think this should
provide relativly accurate resu;ts, at least accurate enough to model
surfaces with a height map.
As for not all the info be contained, maybe I didn't make myself clear, the
y vector never points down but since it's the normal the slope can
decrease. The point <200,200> would be pointing halfway between positive x
and z with a slight incline in the y direction.
I'm still looking of a good way to convert this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> Hi Mienai,
>
> I think there are a few problems with this approach.
>
> One biggy is that the images won't contain some of the information you would
> need in order to create a height field - In particular the height. You would
> need to know the distance of a point from the camera, which the colour
> information in the images doesn't give you.
> With the exception of certain shapes the colour information doesn't give you
> all of the normal information either, because a colour of <200,200> could be
> pointing slightly up or slightly down.
>
> Even if you introduced a third colour and could get good approximate normal
> information you would have to make some quite unreliable assumptions about
> the contours and smoothness of the surface to attempt to derive positional
> information from that. For example, it would still be possible to have a
> step change in the surface height that is inperceptible in the image.
>
> Regards,
> Chris B.
The way I was thinking of it was that the normal is providing the delta in
height (slope) that's why I was thinking that I could just run the image
through a derivative to get an approximate height based of some +c value
(or maybe I need to integrate I forget, should be basic calculus though,
right?). While I agree that there are going to be some
inconsistancies (specially on vertical slopes) I still think this should
provide relativly accurate results, at least accurate enough to model
surfaces with a height map.
As for not all the info be contained, maybe I didn't make myself clear or
I'm not getting what you're getting at. The y vector never points down but
since it's the normal the slope can decrease. The point <200,200> would be
pointing halfway between positive x and z with a slight incline in the y
direction.
I'm still looking of a good way to convert this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<Mienai> wrote in message
news:web.44170d7a925a6bc093db03e80@news.povray.org...
> "Chris B" <c_b### [at] btconnectcomnospam> wrote:
>> Hi Mienai,
>>
>> I think there are a few problems with this approach.
>>
>> One biggy is that the images won't contain some of the information you
>> would
>> need in order to create a height field - In particular the height.
>> ... snip ...
>>
>> Regards,
>> Chris B.
>
> The way I was thinking of it was that the normal is providing the delta in
> height (slope) that's why I was thinking that I could just run the image
> through a derivative to get an approximate height based of some +c value
> (or maybe I need to integrate I forget, should be basic calculus though,
> right?).
> ... snip ...
>
> I'm still looking of a good way to convert this.
>
OK. Well given all the caveats and the implicit innacuracies and the get-out
clause that says I wouldn't do it this way, here's how you might be able to
do it.
The information you've given isn't all that comprehensive, but I'm assuming
that the object is something akin to a height field to start with and that
the objects surface is smooth and of a colour that is uniformly reflective
to green and red light. Also I assume parallel light rays falling on the
surface (i.e. a distant light source where the falloff of light with
distance becomes insignificant in the calculation ). I'm assuming the camera
is above the object looking down from a great distance so that you get an
image where the pixels will map correctly onto the height field you want to
create.
If you process the image pixel-by-pixel you can work out an approximate
x-elevation and a z-elevation across a pixel based upon a normal that is
calculated from the Red and Green colour components of the pixel.
If my thinking on this is correct (based on a quick sketch and a little
paper-based trigonometry) I think the following would give you the normal
<X,Y,Z> of the surface :
X=Red/255,
Z=Green/255,
Y = square root of (1 - X squared - Z squared)
The rise from one side of the pixel to the other in the x-direction would be
Y/X pixel-widths and the rise in the z-direction would be Y/Z pixel-widths.
Note. This is untested and someone with more maths skills than me may be
able to advise if it's not correct.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mienai" <Mienai> wrote:
> So I scanned some real objects with two colors from two different angles to
> produce an image that should more or less be a normal map. I'm wondering
> if anyone knows of a quick/easy way to convert these images into height
> fields.
Hi! Your question and Chris B's replies have resurrected a long-standing
question in my own mind: Whether it's possible to take a 3-D "photo" (made
from two different images, or views, of a scene) and *somehow* use the
information contained in the "difference" (?) between those images to
create a heightfield of the images' objects. True, the result would be
crude, but the technique could produce some intriguing results. It may
or may not be possible, but your posts have spurred me along to
give this some more thought. Thanks!
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mienai,
Take a look at this...
http://66.70.170.53/Ryan/heightmap/heightmap.html
I ran across it while looking for info on normal maps. I think it may
be what you are looking for.
Kyle
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
