Eyeon Talk:Script/Reference/Applications/Fuse/Classes/Image/SamplePixelB

From VFXPedia

< Eyeon Talk:Script | Reference/Applications/Fuse
Revision as of 15:16, 14 December 2010 by Chad (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

How would we go about sampling pixels from an image coordinate? Getting whole pixels is fine if I want to write my own filter, but is there a way we can get bilinear or cubic filtered colors from a 0-1 XY coordinate? Seems like one of those things where it might be common enough. --Chad

Actually, this is the bilinear-filtered normalised-coord pixel sampler - GetPixel() is the non-filtered real-coord function. I've fixed up the docs to better reflect this. --Daniel
Really? In the SDK, the coordinates are int32. Is it different between the SDK and Fuses? If so that would make prototyping a bit more complex if the same function does two different things. If not, is the SDK in error? Or is this some other way of representing the normalized coordinates as int32 instead of float? --Chad
I was wrong - it's not normalised-coord, but it is bilinear-filtered. The fuse SamplePixel functions use floating-point pixel coords, but the SDK SamplePixel functions use 16-bit fixed-point int32 pixel coords (i.e. float pixel coords * 65536). --Daniel


When you say "exactly", how accurate do we have to be with the coordinates to ensure that we do not do the extra bilinear sampling? Or is there no optimization at all for this, and it just does bilinear with very lopsided weights? We're trying to do something like GetPixelB (no filtering, but can be outside of image bounds) --Chad 13:48, 13 December 2010 (EST)

Just using integer pixel coords should be sufficient to avoid any filtering. --Daniel
Ah, right, you mentioned it above, it's not normalized, but float pixel count... I see. Thanks. Would this be faster to do this? Would it be faster with the SDK SamplePixel? --Chad 09:53, 14 December 2010 (EST)