Beiträge von kokoko3k

    I know I'm terribly late on this, but still i'm posting here because using ffmpeg in place of hypergrab-x11 was my first intent, but stumbling across this thread i tought it was just not possible, and i've had to search for alternatives (which, for instance, i found, but are far more complicated)


    Anyway, it works for me the following way (tried with hypersim)

    Hi guys, i made a new grabber that works with x11 and Linux (at least).
    I modified the original HyperionScreen by ellisium, stripped something i didn't need and made some other modifications.


    It is here, requires node and npm:
    https://github.com/kokoko3k/hypergrabx11


    Why another grabber if we already have hyperion-x11?
    Since i really don't like how internal hyperion smoothing works for slow fades and since i like my fades to be really smooth and slow (1 or 2 seconds to go from black to white), i used ffmpeg and tmix filter to achieve that.
    Since hypergrabx11 uses ffmpeg, it is really easy to expand his functionalities ( provided you know how to use ffmpeg).
    Cpu use is good; on an i5-4590@3.3ghz i can grab 1920x1080 at 15fps with default settings, about 3%
    All of the settings configurable in the settings.json file.


    Have fun!

    Ok, after several testing, i understood that unfortunately the smooth routine "queues" fades.
    I modified my sketch to fade itself and disabled the smoothing in hyperion, here it is, works well for me.



    It provides smooth and slow (play with the speed value) color fades; it differs by the hyperion implementation because it reacts immediately to the requested changes instead of waiting for the previous fade to complete.
    Think at it as a sort of real time temporal smoothing.

    Hi, i'd like to understand better how color smoothing works.
    I know, given a start color and an end color, it interpolates between them over a specified amount of time at a specified refresh rate, fine.
    What i've not understood is the timing, an example with just one led should be clear:


    [INDENT]Imagine i've set a slooow smoothing over 1000ms.


    a) time 0ms : tell hyperiond to display 0,0,0
    b) time 500ms: tell hyperiond to display 255,255,255
    c) time 1000ms: tell hyperiond to display 0,255,0


    What will happen?
    a) To simplify things, suppose that at time 0 there is no smoothing triggered.
    b) At time 500ms, hyperion will start to fade from black to white; and given the high smoothing time of 1000ms, the fade is expected to stop at time 1500ms.
    c) "BUT" at time 1000ms, i tell hyperiond i want green instead, and by that time, the previous fade (b2w) is still going on, it is in the middle, and probably the led is a perfect gray (128,128,128).


    So i'd like to know what would the happen at time 1000ms.
    Does the fading stop and another fade starts just from 128,128,128 to 0,255,0 or will hyperiond wait for the first fade (b2w) to finish, before starting the new one from 255,255,255 to 0,255,0?[/INDENT]



    I hope i've been clear enough, thanks.

    The following works:




    What one should expect from the code above is to gain more precision at lower brightness, NOT better color fidelity.
    In fact, you actually lose the ability to set different gamma values for r,g,b.

    So, a dark color will appear dithered (better), but a color like this: 255,255,1 would not gain anything; this is because FastLed library does not provide different brightness per channel, just a global one; that means that 255,255,1 wil still be reproduced (after applying gamma) as 255,255,0.


    You will notice that gamma correction is done inside the sketch (#define Gamma 2.6), and it is done using float values; this is needed to gain extra precision (or hyperion would just cut it to integer).


    What the code does:
    1 reads the color to display, and compute its gamma and store it in float.
    2 Find the maximum value and use it as the master brightness factor
    3 stretch/normalize the color to full range/brightness
    4 display


    That way, the FastLed dithering should work; one thing i'm not 100% sure is still where to put FastLED.delay.
    By now i've put it inside the main waitloop, and it will wait/dither in 16ms steps; this means that arduino will see if there is data available on the serial every 16ms; this could introuduce some lag (well...16ms is not that much).


    I hope to receive some code review ;)

    Hi, i'm finally playing with hyperion and a ws2811 led strip.


    I'm using PC -> Arduino+fastled (adalight) -> led strip.


    After i configured the gamma ramp, i'm facing the problem that the lower btightness appears just black.
    So i documented myself and i've found that the fastled library actually implements temporal dithering, but the way it does it is not directly accessible by hyperion, because, as stated here:


    I'm using a sketch from here, and in the code i read the following:


    Code
    leds[i].r = r;
        leds[i].g = g;
        leds[i].b = b;
      }
      // shows new values
    FastLED.show();


    ...but what if we do something like this:


    Code
    //imagine we want to show a perfect gray (127,127,127)
       leds[i].r = 255;
       leds[i].g = 255;
       leds[i].b = 255;
    FastLED.setBrightness(127);
    FastLED.show();


    Basically, my idea is to stretch the luma component to full range, and then call setBrightness accordingly to scale them down so that the fastled temporal dithering would kick in.
    I suppose we also need to add FastLED.delay() into the sketch main loop (it is not clear to me if it needs to be done or not)


    Q: "Why don't you test it by yourself?"
    A: "Because i will be back at home in a month, and i just have had this idea :)"


    What do you think? would it work?