Beiträge von redPanther

    I use my desktop linux system. I use hypersim as virtual leddevice and arduino+adalight to test serial and to see ot on my real lamp I send led data over network to my fadecandy server.


    Compile is faster as on any pi and I have all my editors/tools that I usualy use for development

    sorry for you.


    I can imaginge we extend hyperion-v4l2 with a new function that outputs the settings for the threshold.


    should work like that:


    ./hyperion-v4l2 --getNoSignalThresholds
    > remove signal cable from your grabber and press <enter>
    "redSignalThreshold" : 0.0,
    "greenSignalThreshold" : 0.0,
    "blueSignalThreshold" : 0.8
    > don't forget to reconect your signal cable!


    then you can set the evaluated values in config file. In future we can set the evaluated values directly into config without manual editing.

    you can select the color with that threshold. grabbers sending green, also possible. I know there are some crazy devices out there that send some rainbow pattern ... this would be a bit hard. For all grabbers with a specific color there is a solution

    for A/D videograbber this is the only chance you have.
    There is a hardcoded framecounter threshold currently set to 50. This means if 50 frames fullfills the threshold condition, no frames send to hyperion core. After priority timeout the used prio channel in priomuxer will be clean and the next prio channel is visible.


    We can make the threshold counter available in config so you can set it to your needs. Default could be current value(50)


    (when my lightberry arrives I will investigate that :) )

    why we dont use the signal threshold detection already build in v4l2 grabber?


    "grabber-v4l2" :
    {
    "device" : "/dev/video0",
    "input" : 0,
    "standard" : "no-change",
    "width" : -1,
    "height" : -1,
    "frameDecimation" : 2,
    "sizeDecimation" : 8,
    "priority" : 900,
    "mode" : "2D",
    "cropLeft" : 0,
    "cropRight" : 0,
    "cropTop" : 0,
    "cropBottom" : 0,
    "redSignalThreshold" : 0.0,
    "greenSignalThreshold" : 0.0,
    "blueSignalThreshold" : 0.0
    },

    I had probs with wifi. After connecting all devices to my gb switch problems disapear and there is no latency. Perhaps you can connect rpi and pc via cable to same switch for testing ...

    how about taking the wether as additional component. Atm it rains in my location and it is quite dark ... we can use internet weather services.


    this informations (weather, sunset/sunrise, season) can be published to effects to - the effects can react on those environmental things

    for the brightness: how about calculating the times for sunset and sunrise. Then we can define time regions like night, day dawn, ... and then assign maximum brightness values to this time reagions. Then we can interpolate between those values during the day.


    To make it perfect, we can add a seasonal component (winter, spring, summer, winter).


    here is some code and theory to calcualte sunset/sunrise
    http://lexikon.astronomie.info/zeitgleichung/neu.html (german)

    it is possible, but not so easy. In config we can do all we want, but inside hyperion we can't change much for that topic.



    if spillting boot/idle:
    - set boot prio hardcode to 0, if it was before I start to modify it.
    - at the same time (all those things are in threads - think parallel :) ) set your static/background color or effect with a prio channel e.g. 9999
    - throw an error when boot time is 0 (infinity)


    Then boot is always shown, because it has prio channel 0. After effect finished, channel 0 is cleared and next higher channel is visible. If no prio channel (below idle channel of 9999) is active, the idle effect/color will appear.


    If a clearAll is send, all channels, including the idle channel is cleard and you leds have nice black color.


    This is much like we do it now, except we start 2 effects at boot instead one.


    BTW I think it doesn't interfere with minimum lumiance, because when this is active a grabber will be active and this overrules the idle/background effect/color anyway


    idle effect/color will displayed when no other grabber/effect/color is active. If you use a grabber configured by "framegrabber" you will never see idle effects, because the grabber is always on.

    I wrote a qt program to test the stuff. (easier to learn octivae ;) ) I found the error (the modulao for hsitogramm wasn't correct) and now looks pretty cool. I will fix my hyperion hack and I hope that it looks good with video to.


    her my algorithm:
    [MEDIA=pastebin]nFwkEbN9[/MEDIA]

    I tested another thing. avarage over whole pic. transform resulting color to HSL space. then limit L in range 0.4-0.6 and set S to 1, then transform back to RGB spce. This looks quite nice. With smoothing I can adjust how jumpy the whole thing is

    here my approch.
    [MEDIA=pastebin]E05dA4Un[/MEDIA]
    replace imagetoleds.h with my file. I recommended to enable smoothing, because we cant calculatate over more than one frame asa suggested in the article.


    Perhaps I did domething wrong or sombody can make it better .....


    edit:
    switch back to partSize=16 and in line 226 the "C" from 0.2 to 1.0
    added ignore partion 0, for some reason all "none important colors" will be co8unt there. (it increases to much). Todo so change in line 233 i=0 to i=1


    now I get OK results - watching "big buck bunny" lokks good. watching "star trek horizon" is mostly OK but somtimes the color switches to fast between to diferent colors.


    mybest smooting settings so far for that: time: 600, frq: 24, delay: 0