jit.3m – like analysis in shaderland?

Apr 21, 2007 at 7:56pm

jit.3m – like analysis in shaderland?

hi
Following the previous shader thread, I was wandering- is it possible to do jit.3m like analysis of the color levels in a texture using a shader?
Also, is it possible to create a “ji.unpack” analogue using a slab?
Pardon me if these questions bely a great lack of shader knowledge… I admit, I still didn’t get to most of the orange book…
thanks
Nadav

#31515
Apr 22, 2007 at 5:36pm

On Apr 21, 2007, at 12:56 PM, Nadav Assor wrote:

> Following the previous shader thread, I was wandering- is it
> possible to do jit.3m like analysis of the color levels in a
> texture using a shader?

These type of algorithms are harder than most in a shader due to the
processing model. What one typically does is an iterative
downsampling of textures–e.g. take one texture, break it in two
(half size) and use something like jit.gl.slab @file op.min.jxs (or
avg or max), and then break the output in two (halfsize), and do the
same thing again, etc. Depending on your implementation, this may or
may not be any more efficient than doing on the CPU.

> Also, is it possible to create a “ji.unpack” analogue using a slab?

Textures are always 4 planes and there is no provision in our
implementation for rendering to multiple texture targets, but you can
take a peek at the cc.colormap.jxs for an example of how you can
remap color channels. For example, you could use 4 instances of
jit.gl.slab @file cc.colormap.jxs to essentially accomplish this
task, each instance set to map all of one color channel to the 4
output color channels.

Shader based processing (stream processing) is quite different from
traditional CPU based processing, so I would suggest you read up
further on the subject if you’re interested in this sort of thing.

-Joshua

#102578
Apr 22, 2007 at 6:29pm

I had a feeling this would be the case. Thanks for the thorough explanation, lots to learn…
I do wonder though, if there’s a way that’s cheaper on the cpu to do what I’m after-

In short what I’m trying to do is analyse an incoming video matrix for it’s mean rgb values, and pass through only the plane with the highest mean value – so that at any given time only the green, blue or red plane is output from the signal, whichever has more pixels.

As my pipeline is other than this process completely slab-based and working nicely, I’m really looking for a cheaper solution than my current jit.3m + operators + planemapped jit.matrix combo, this takees me down by about 10 fps.

Any ideas are welcome…
Thanks
Nadav

#102579
Apr 23, 2007 at 12:53am

Writing a custom Jitter external will defeintely be the best solution.
I believe that jit.3m is one of the projects, so you can start with
that code.

wes

On 4/22/07, Nadav Assor wrote:
>
> I had a feeling this would be the case. Thanks for the thorough explanation, lots to learn…
> I do wonder though, if there’s a way that’s cheaper on the cpu to do what I’m after-
>
> In short what I’m trying to do is analyse an incoming video matrix for it’s mean rgb values, and pass through only the plane with the highest mean value – so that at any given time only the green, blue or red plane is output from the signal, whichever has more pixels.
>
> As my pipeline is other than this process completely slab-based and working nicely, I’m really looking for a cheaper solution than my current jit.3m + operators + planemapped jit.matrix combo, this takees me down by about 10 fps.
>
> Any ideas are welcome…
> Thanks
> Nadav
>

#102580

You must be logged in to reply to this topic.