PDA

View Full Version : X-Motion and Y-Motion-- what exactly are they?



jeric_synergy
05-01-2012, 12:56 PM
You can easily output the X&Y Motion buffers using the LW Composite Buffers Export (which generates image streams, AFAICT, not layered/embedded image files).

But, looking at the resulting files, I'm confused.

http://www.youtube.com/watch?v=B_m9R7vcioQ&feature=youtu.be

realgray
05-01-2012, 01:15 PM
They are LW's way of exporting an Mblur pass. A lot of fusion artists have workflows that make use of these for Mblur.(there are threads about this) As an AE guy I can only hope that someday Lightwave has a Motion Vector export. (or use Modo)

jeric_synergy
05-01-2012, 01:33 PM
I know what they are. What I mean is: how is the data encoded into the two images? How do you translate the pixel value into a direction vector?

I'm guessing it's something like :


0=xmotion left
127= no xmotion
255= xmotion right

Along those lines.

Captain Obvious
05-01-2012, 02:02 PM
I think it's actually zero equals no motion, negative equals left/down motion and positive equals right/up motion. Not sure though.

jeric_synergy
05-01-2012, 02:25 PM
I think it's actually zero equals no motion, negative equals left/down motion and positive equals right/up motion. Not sure though.
Pixels are 0-255. There is no negative in a non-float pixel.

Lightwolf
05-01-2012, 05:56 PM
I think it's actually zero equals no motion, negative equals left/down motion and positive equals right/up motion. Not sure though.
Precisely. The motion buffer contains the distance, measured in pixels, that the content of the specific pixel moves due to motion along the X and the Y image axes.

Pixels are 0-255. There is no negative in a non-float pixel.
Then either the exporter needs to squeeze them into the limited range of the file format or you lose the data. Which would be anything that moves in a negative direction (all negative numbers) and any distance further than 1.0 along positive X and Y (remember 1.0 float is mapped to full white in LDR images).

Cheers,
Mike

warmiak
05-01-2012, 06:29 PM
Pixels are 0-255. There is no negative in a non-float pixel.

Then I guess normal maps must be some sort of black magic since they need to be able to encode normalized vectors :-)

It is quite easy - it all depends how you encode and decode these values and as long as you understand various precision issues, you can come up with anything you want.
http://en.wikipedia.org/wiki/Quantization_(signal_processing)

jeric_synergy
05-01-2012, 06:55 PM
Then I guess normal maps must be some sort of black magic since they need to be able to encode normalized vectors :-)
Normal maps have an encoding, now where have I seen that word before? Oh yeah:

how is the data encoded into the two images? How do you translate the pixel value into a direction vector?

jeric_synergy
05-01-2012, 07:01 PM
Precisely. The motion buffer contains the distance, measured in pixels, that the content of the specific pixel moves due to motion along the X and the Y image axes.

Then either the exporter needs to squeeze them into the limited range of the file format or you lose the data. Which would be anything that moves in a negative direction (all negative numbers) and any distance further than 1.0 along positive X and Y (remember 1.0 float is mapped to full white in LDR images).
It appears that Composite Buffer Export doesn't do that with non-float formats, so the moral of the story is "Use float formats".

Lightwolf
05-01-2012, 07:06 PM
Then I guess normal maps must be some sort of black magic since they need to be able to encode normalized vectors :-)
And they do. A mechanism quite close to what RSMB expects as vector motion data.
O.k., so it's more like grey magic at best... ;)


It is quite easy - it all depends how you encode and decode these values and as long as you understand various precision issues, you can come up with anything you want.
http://en.wikipedia.org/wiki/Quantization_(signal_processing)
While Quantisation plays a part in it, it's not the deciding factor. Just saying, it's a bit of a red herring in this context.

Cheers,
Mike

warmiak
05-01-2012, 08:27 PM
And they do. A mechanism quite close to what RSMB expects as vector motion data.
O.k., so it's more like grey magic at best... ;)

While Quantisation plays a part in it, it's not the deciding factor. Just saying, it's a bit of a red herring in this context.

Cheers,
Mike

Actually it is .. at least if you limit yourself to 24 bit RGB images.

Captain Obvious
05-02-2012, 12:21 AM
It appears that Composite Buffer Export doesn't do that with non-float formats, so the moral of the story is "Use float formats".
When it comes to 3D rendering, isn't that always the moral of the story?

OpenEXR will make your life easier. Just get used to it.

Lightwolf
05-02-2012, 01:19 AM
Actually it is .. at least if you limit yourself to 24 bit RGB images.
Quantisation is related to the degree of how well a certain range of values can be represented with a limited numeric precision. It affects all bit formats.

However, the main problem here is the fact that LDR image representations (regardless of the bit depth) don't even cover the range to start with.

Cheers,
Mike

warmiak
05-02-2012, 05:52 AM
Quantisation is related to the degree of how well a certain range of values can be represented with a limited numeric precision. It affects all bit formats.

However, the main problem here is the fact that LDR image representations (regardless of the bit depth) don't even cover the range to start with.

Cheers,
Mike

Of course it does - it is just a matter of how little precision you can get away with it.
You just drop your precision by half and you can encode -127 ... 128 ranges.

Lightwolf
05-02-2012, 06:09 AM
Of course it does - it is just a matter of how little precision you can get away with it.
You just drop your precision by half and you can encode -127 ... 128 ranges.
And even then you need to change the range of representation (and interpretation for that matter, as 8-bit file formats always imply unsigned bytes).
Which is the issue here. Precision isn't, that's the next step. ;)

Cheers,
Mike

warmiak
05-02-2012, 07:51 AM
And even then you need to change the range of representation (and interpretation for that matter, as 8-bit file formats always imply unsigned bytes).
Which is the issue here. Precision isn't, that's the next step. ;)

Cheers,
Mike

There is no other way - you always have to make assumptions about what is being represented by a byte and decode it appropriately.
Even CPUs work that way - they have no clue if something is signed or unsigned - you have to tell them to interpret this value in a certain way.

The fact that 8 bit formats imply unsigned bytes is irrelevant - you cannot create "invalid pixels" by encoding values in this way.

You just gonna end up with funky looking images ( just like normal maps) but it doesn't matter since this wasn't a real image in the first place.

Lightwolf
05-02-2012, 07:54 AM
There is no other way - you always have to make assumptions about what is being represented by a byte and decode it appropriately.
If you call specs "assumptions", then I agree. However, the point of specs is usually to relieve developers of needing to make them in the first place.

That's usually also a requirement for interoperability... which sends us back to square one on this thread. ;)

Cheers,
Mike

warmiak
05-02-2012, 08:11 AM
If you call specs "assumptions", then I agree. However, the point of specs is usually to relieve developers of needing to make them in the first place.

That's usually also a requirement for interoperability... which sends us back to square one on this thread. ;)

Cheers,
Mike

Well, specs only matter if you are trying to operate on an image according to specs - i.e using Photoshop or something like that and with a vector field , why would you want to do that ?

As far as interoperability - you have the same problem with normal maps , they are meaningless as images and you have to know what is being encoded in them to make use of them.

Going back to the original question - if Newtek offers no specs for that it wouldn't be that hard to decode a set of known vectors and see what comes out on the other side.

Lightwolf
05-02-2012, 08:16 AM
Going back to the original question - if Newtek offers no specs for that it wouldn't be that hard to decode a set of known vectors and see what comes out on the other side.
LW isn't the problem... other applications are. In some case the expected format it know, in some apparently not.
However, it still requires intervention by the user if the expected format isn't the native format of LW.

Cheers,
Mike

warmiak
05-02-2012, 08:31 AM
LW isn't the problem... other applications are. In some case the expected format it know, in some apparently not.
However, it still requires intervention by the user if the expected format isn't the native format of LW.

Cheers,
Mike

Well, this is not a perfect world :-)

Height map images, normal maps, displacement maps, you name it - they all require user intervention ( sometimes you have to tell your decoder to flip an axis, make implicit assumptions that white values represent peaks etc ) - there is now way to know these things just by looking at the image itself.

Lightwolf
05-02-2012, 08:33 AM
Height map images, normal maps, displacement maps, you name it - they all require user intervention ( sometimes you have to tell your decoder to flip an axis, make implicit assumptions that white values represent peaks etc ) - there is now way to know these things just by looking at the image itself.
Precisely. And those are also explicitly the stages where quantisation is of no importance. Once you're past that, then it comes into play.
But we're not there yet... ;)

Cheers,
Mike

jeric_synergy
05-02-2012, 08:56 AM
When it comes to 3D rendering, isn't that always the moral of the story?

OpenEXR will make your life easier. Just get used to it.
1) Seems that way. :D
2) I'm tryin'...

I wonder how long it'll be before my change jar has 39 in it.

warmiak
05-02-2012, 09:17 AM
Precisely. And those are also explicitly the stages where quantisation is of no importance. Once you're past that, then it comes into play.
But we're not there yet... ;)

Cheers,
Mike

Well, don't want to beat a dead horse but these are the stages where quantization matters the most.

All these "assumptions" are essentially input/range values for the whatever quantization algorithm is being used and will differ accordingly.

Lightwolf
05-02-2012, 09:47 AM
Well, don't want to beat a dead horse but these are the stages where quantization matters the most.
If you look at the code, then the actual quantisation (irreversible many-to-few mapping) happens last.
Certainly from a practical PoV (and if you exclude the fact that floats inherently quantise anyhow).
I suppose the difference in opinion may be because you see it as one process while I distinguish two distinct steps.

Cheers,
Mike

Greenlaw
05-02-2012, 10:30 AM
I don't understand everything being discussed here but this is like watching a tennis match. :)

warmiak
05-02-2012, 11:31 AM
I don't understand everything being discussed here but this is like watching a tennis match. :)

There is no real disagreement here just semantics imho.


Anyway, this whole quantization process is a fancy name for what can be as straightforward as simple addition/substraction/division.

For instance if you have a normalized floating point scalar (0 to 1.0f) you can "quantize" it into a byte ( 0 -255) by simply multiplying that value by 255 and converting to an integer.

For instance if you have float val1=0.567; and float val2=0.565;

Multiply both by 255.0f and you end up with:

float res1= 144.585;
float res2= 144.075;

Now you convert them to an integer and you end up with the same value:
144.

You can now store that value into an 8 bit image which supports only 0-255 integer ranges.

To convert it back to float, just cast it to a float (144.0f) and then divide by 255.0f and for both numbers you end up with:

float res1= 0.564706;
float res2= 0.564706;

We started out with 0.567 and 0.565 and ended up with 0.564 for both values.
In other words we used to have to different float values but now we have the same value which is "close enough".

This is all there is too it (a very simple case admittedly ) - it is in a sense a version of lossy compression scheme like jpegs ( which are much more complicated) - you can get a close-enough representation of the original but once you convert it , you can never "get it back" in its original form.

That's how normal maps work ( actually it is bit more complicated since normal maps deal with -1.0f to 1.0f ranges but you end up simply encoding your values into 0-128 ranges as opposed to 0-255 and thus you have less precision but support negative numbers)

gerardstrada
05-07-2012, 06:52 AM
Just in case, here (http://lightwiki.net/wiki/Multipass_Rendering_with_Filter_Node_Editors#Motio n_Vectors_for_RSMB_.28Update.29) there's a way for getting motion vectors for RSMB through DP FNE.



Gerardo

P.D. Hope upload the nodes setups soon.

Lightwolf
05-07-2012, 08:26 AM
Just in case, here (http://lightwiki.net/wiki/Multipass_Rendering_with_Filter_Node_Editors#Motio n_Vectors_for_RSMB_.28Update.29) there's a way for getting motion vectors for RSMB through DP FNE.



Gerardo

P.D. Hope upload the nodes setups soon.
You could probably simplify this to two nodes (one per scalar) using Remap from the db&w Tools.
I.e. remap -2048 / 2048 to 0.0 / 1.0 - that should work.

Cheers,
Mike

gerardstrada
05-07-2012, 09:26 PM
That's a clever solution, Mike! :thumbsup:

I've updated the article with your suggestion. At least according to my tests here, we would still need a couple of more nodes for gathering both scalar Remap outputs in a single vector and for inverting this according to what RSMB expects. Surprisingly, the input value for matching the previous results is not so high (just + - 8.0). Since 4 nodes is the minimum number of nodes I could get, I went for a single Remap node.

Thanks a bunch for your contribution and so useful tools,



Gerardo

Lightwolf
05-07-2012, 09:32 PM
I've updated the article with your suggestion. At least according to my tests here, we would still need a couple of more nodes for gathering both scalar Remap outputs in a single vector and for inverting this according to what RSMB expects. Surprisingly, the input value for matching the previous results is not so high (just + - 8.0). Since 4 nodes is the minimum number of nodes I could get, I went for a single Remap node.
Yeah, makes sense if you need to massage individual values. You might be able to get the invert to work with Remap as well if you swap the min/max values (just thinking aloud). But in the end it would probably only make things harder to read without saving any nodes.


Thanks a bunch for your contribution and so useful tools,

Thanks, and you're very welcome.

Cheers,
Mike

gerardstrada
05-07-2012, 09:37 PM
Yeah, makes sense if you need to massage individual values. You might be able to get the invert to work with Remap as well if you swap the min/max values (just thinking aloud). But in the end it would probably only make things harder to read without saving any nodes.
Yes, I tried by switching the min/max values, but for some reason the final color coding is not the same.


P.D. Just in case, this is what I'm doing:

http://s16.postimage.org/y5rzvxeth/colordif.gif

Though it probable has no incidence in final RSMB results.



Gerardo