Setting RGB pixel order in the SPI backend?

[Steve French]

Hello!

I have a situation where a Python program is handling the artistic front-end RGB pixel generation side of things.  When you hook the physical pixels to the SPI port, sometimes the pixels are manufactured with a different color sequence order.  Sometimes it is RGB and sometimes RBG, etc.  Usually I have seen this hardware-dependent swapping of color orders handled on the last stage before the data goes out the door, which in this case is the OLA SPI plugin.  Does it make sense to have the OLA SPI plugin have the ability to choose/swap color order (RGB, RBG, GRB, GBR, etc)?  Maybe as an RDM personality or something?

I guess one argument against this is that there are lots of pixels coming that are RGBA (4channels/pixel), RGBW (4channels/pixel), Whiteonly (1channel/pixel), WarmWhite/CoolWhite (2channels/pixel), 16bits/color pixels, etc.  ...and I guess it is unrealistic to have OLA handle all of the various options.  Not sure...just thought I would ask the question.  I guess for now I will swap the color order on the front end.  Let me know of any comments.  Thanks!

thx!

frenchy (Steve French)

www.voltvision.com

[Stefan Krüger]

Hi Steve,

we had this discussion some time ago in chat -
conclusion was - no - the output should only convert transparently.
all other task should be done by 'the new patch system'... (its there on the wishlist)

i needed some similar re-mapping - and so i have wrote a python script that reads one universe and outputs on another -
https://github.com/s-light/OLA_channel_mapper
the python script can also generate a full 'mapping table' as input for the cpp script..
it can do 'repeat' and 'reverse' patterns.. (all things i needed ;-) )

after this i stripped down and converted this to a c++ version:
https://github.com/s-light/OLA_channel_mapper_cpp
this one is not finished..
its a quick hack - but works..

i checked the two scripts on my 400MHz Arm CPU @30ms update rate incoming packages:
python script: ~70% CPU load
cpp: ~4% CPU load

the python script reconnects to olad if it is stopped and restarted..
for the cpp - i would have to learn more cpp and olad api to make it cleaner..

eventually it helps..

sunny greetings
stefan

[Peter Newman]

Hi Steve,

Yes as mentioned it's covered here:

https://github.com/OpenLightingProject/ola/issues/280

And for now with people's custom scripts. It's one of those tasks where the actual byte shuffling programming is pretty trivial, but making something that's easy to use and a decent UI for it is the real challenge, which I suspect is one of the reasons no-one has started and various people have written their own custom bits of code to do their specific job.

Stefan, I'm surprised your Python load is so high, I wasn't running mine on a Pi, but I wrote a DA/splitter script as a test and that seemed to barely break a sweat.

[Stefan Krüger]

Hi Peter,

what do you mean with 'DA/Splitter' ?
i don't know exactly what is using up the cpu time - but its somewhat my python code...
if i only send all 100ms a packet the script needs about 20%CPU (its only a 400MHz ARM9 CPU with 128MB Ram --> so less than Pi)
and i have in no way optimized this for speed - its more optimized for easy handling..
one thing is - i have abstracted the ola api with threading so that my main script can do other things at the same time..
there a a bunch of things that can hook the cpu with this..
eventually i will try to make a 'minimal' python version just for comparison.

sunny greetings
stefan

[Peter Newman]

I just wrote a trivial script that when it received an update on universe A, it sent the same data out on universes B and C. This was the beginning of a test for some other data manipulation, to split one universe across two.

Have you considered separating out the shuffling code from your other core code, which probably means you could avoid abstracting the OLA API?

[Stefan Krüger]

Hi Peter,

today i have made a simplified version of my mapper..
its available at https://github.com/s-light/OLA_channel_mapper_simple/

i have stripped out about all that i think i could.(there is only one helper module but this is only for reading the configuration file)
https://github.com/s-light/OLA_channel_mapper_simple/blob/master/olamapper.py
the cpu values did not really change..
on my main machine (core i7 Q 720 @1.6GHz) the mapper has about 10% cpu of one core with an input of 10ms frames

eventually i just do something heavily time-consuming and did not find it?

sunny greetings
stefan