14 lines
2.8 KiB
Markdown
14 lines
2.8 KiB
Markdown
|
Hey, have a look at @docs/2d-3d-mathobjs-and-operation-libs.md , and now I need to think about adding a camera stimbuff device which will ultimately present each of the channels of the YUV input as its own greyscale stimbuff; and then I'll also have 2 intrins on the brighness channel -- 1 negtrin and 1 postrin. We need to be forward thinking about our code modules and isolate code which is common so that we can reuse it when creating a future xcbWindow and later, a waylandWindow stimbuffapi lib. AFAICT, the main difference is that the camera stimbuff can give us yuv/hsv directly, whereas the window managers will give us RGB which we'll have to convert to hsv in an extra step. So it seems like we have a common pipeline to some degree: all of them are ultimately aiming to produce hsv/yuv channel-split greyscale stimbuffs.
|
||
|
|
|
||
|
|
Now to implement the intrins on the brightness stimbuff, it'll be just a loop in the production pipeline where we look for any channel values that exceed the intrin's thresholds, and we'll create different masks (within each intrin): one mask for those that exceed intolerable/stupefying-thr, one for those between distraction-thr & stupefying, and one for those between interest-thr and distraction.
|
||
|
|
|
||
|
|
We'll construct masks (I think?) from those, and those will be our stencils. So it seems like stencil type varies widely across the different stimbuff types. So the stencil type for image channel data will prolly be masks? And we'll attach values to those for comparator-references.
|
||
|
|
|
||
|
|
I imagine that other stimfeat types like sound channels, etc will have their own stencil types. So we need to lean into the piolymorphism of our current stencil base class and try to get good abstractions for constructing them as derived type objects from particular data types, and then ensuring that an agnostic component can use them via polymorphic function calls and get the correct results.
|
||
|
|
|
||
|
|
Then, we'll need to be albe to create shape vectors for the masks/stencils.
|
||
|
|
Then we need to be able to create comparators which can compare these shape vectors, and compare the values of two rasterized subregions of of data?
|
||
|
|
|
||
|
|
I think the term stencil is itself becoming ambiguous now because it seems I'm trying to denote both the regions of interesting rasterized data, and a notion of a clipping mask that records what that region is? Or maybe the stencil is both of those things together -- i.e, a stencil abstraction is represented by both of those things acting in concert and the stencil notion cannot be algorithmically completely implemented without both together.
|
||
|
|
|
||
|
|
Give me recommendations for how you'd approach this, and take into account the need to create and isolate some shared commonLibs/ .so library that uses OpenCV or whatever other abstractions in a way that can eventually be reused for the window manager screen recording stimbuffs we'll eventually implement.
|