Adalight Reloaded: Super Elite Chuck Norris Edition! Moderators: adafruit_support_bill, adafruit

[pburgess]

Funny how that happens...I'd gone in just to test out a little change to the Adalight code, and ended up spending most of the weekend on a nearly complete rewrite with a double-helping of awesomesauce! This involves changes on both the Arduino and Processing sides, and as always you can download the latest from the Git repository:

https://github.com/adafruit/Adalight

(New visitors: if you're just joining us, this is Adalight: http://ladyada.net/make/adalight/ )

So what's new?

• Support for multiple monitors. There have been occasional tweaks and suggestions posted to the forums on achieving this. Here's the official implementation. Handles any number of displays, and each can be a different size/layout if needed.
• Performance improvements. The exact speedup you'll see depends on many factors, but a few systems we've tested show anywhere from 10 to 30 percent better frame rates.
• More nuanced lighting control. LEDs "fade" from frame to frame, rather than an immediate, seizure-inducing flash. Also, a minimum background brightness can be set. Both are configurable, or can be switched off to run like the old code.
• Auto timeout on LEDs. If the Arduino doesn't receive any data from the PC in 15 seconds (configurable), the LEDs will be switched off. This avoids that annoying "stuck pixel" effect when quitting the Adalight sketch in certain situations.
• Automatic port detection. Adalight can scan through all serial ports until it identifies an Arduino running the LEDstream code. Update: due to a conflict between Processing 1.5.1 and the 32u4 board, this doesn't work in all settings, so it's no longer the default mode. If you're using a "classic" Arduino and/or Processing 2.0 alpha, this should work fine, you'll just need to enable that code (very easy, see comments in source).
• 100% gluten-free, and no trans-fats! No animals were harmed in the making of this software. Any time the cat wanted food or to go outside, I'd stop working and take care of it.

Load the "LEDstream" sketch in the Arduino IDE, compile and upload to your board. Then load the "Adalight" sketch in Processing and give it a try...and remember, you can always use the "Export Application" feature in Processing to create a standalone double-clickable program; no need to launch the Processing IDE every time you want to run Adalight.

The old LEDstream and Adalight are both cross-compatible with the newer versions, so reprogramming the Arduino isn't absolutely 100% essential if you can't get to it...they both still speak the same protocol. This is mostly for the LED timeout and auto-detection in the new code.

[Taifuuni]

Fantastic! Thank you very much. Almost hitting 25 FPS now. Now I only need to buy some plastic sheet to mount my leds. My electric tape attempt isn't holding up to my standards :D

[nahiko]

Hi!!

Nice work!!
Now you need few more things, how about autodetenting black bars every... 15 seconds and setting an offset to get the average colors avoiding the black bars?
It is REALLY nice the auto timeout, the auto port detection and OF COURSE the fading feature :D

BUT as I said before, i do not agree with this:

Code: Select all | TOGGLE FULL SIZE

  // Capture each screen in the displays array. Full screens are captured,
  // even though typically only the perimeter is used. Logically it might
  // seem that capturing just the sampled areas would be faster, but in
  // practice this is not the case...there's a certain latency associated with
  // each capture action, and so one large block capture generally finishes
  // sooner than a multitude of smaller ones.

try this simple java program:

Code: Select all | TOGGLE FULL SIZE

import java.awt.AWTException;
import java.awt.Rectangle;
import java.awt.Robot;
import java.util.Date;
import java.awt.image.BufferedImage;


public class AmbiDos {

   Robot r = null;
   
   public AmbiDos(){
      try {
         r = new Robot();
      } catch (AWTException e) {
         e.printStackTrace();
      }
   }
   
   public static void main(String[] args) {
      
      AmbiDos ambi = new AmbiDos();
      BufferedImage ss;
      Date d;
      Date dd;
      for(int p=0; p<10; p++){
         d = new Date();
         for(int i=0; i<250; i++)
            ss = ambi.r.createScreenCapture(new Rectangle(0,0,1440,900));
         dd = new Date();
         System.out.println("Big screenshots time: ");
         System.out.println(d.getTime()-dd.getTime());
         
         ambi = new AmbiDos();
         d = new Date();
         for(int i=0; i<250; i++){
            for(int j=0; j<25; j++){
               ss = ambi.r.createScreenCapture(new Rectangle(i,j,20,20));
            }
         }
         dd = new Date();
         System.out.println("Small screenshots time: ");
         System.out.println(d.getTime()-dd.getTime());
      }
   }
}

As you will see, the diefrences in time are BIG and that is with just 1440x900, using 1680x1050 or 1920x1080 they would be even bigger

Cheers!!

[pburgess]

Hi nahiko,

Believe me, I've tried a number of approaches and have benchmarked these things...repeatedly...and the full-screen grab always worked out faster overall than the multiple "grablets." In fact, testing the code you just posted, the multiple small grabs took about twice as long as the full screens. This might be something endemic to the different hardware configurations we're each testing with.

[nahiko]

Hi!!

Yes yes, of course I believe you!! I see you did a great job, I was confusing why you did not use the multiple small grabs instead, but if you tell me you tried it and the results were worse, I believe you of course!!
In my code if I just take one big screenshot the framerate goes down, and with the multiple small grabs it works much faster.

It will be something with the... I do not know, graphics card? I have a nVidia 470, or I do not know, but it certainly is weird.

Look at the difference in my computer:

Code: Select all | TOGGLE FULL SIZE

Big screenshots time:
-11000
Small screenshots time:
-312
Big screenshots time:
-11047
Small screenshots time:
-282
Big screenshots time:
-11062
Small screenshots time:
-281
Big screenshots time:
-11016
Small screenshots time:
-281
Big screenshots time:
-11032
Small screenshots time:
-265
Big screenshots time:
-11016
Small screenshots time:
-281
Big screenshots time:
-11016
Small screenshots time:
-281
Big screenshots time:
-11016
Small screenshots time:
-282
Big screenshots time:
-11031
Small screenshots time:
-266
Big screenshots time:
-11015
Small screenshots time:
-282

Keep improving it and adding new features!! :D

Cheers!!

[pburgess]

Whoa...huge difference! Well, what I'll do, next time I have a little time to fiddle on this again, I'll add an option to make it use either technique. Folks can then try it both ways and pick the method that runs better with their system configuration. I appreciate your help in coming up with that benchmark!

[hoogerd]

That's great news Phil!

I'll try it immediately when I come home tonight, and hope it will fix my framerate issues that seem to be caused by a 16 or 32 bit setting ( see my other post)

[hoogerd]

just got home early and tried the new code, and although there improvement on the framerates, with 32bits it gets stuck at around 11fps, while with 16 bits it hits 40fps!

Am I the only one using 32bit display color depth ? viewtopic.php?f=47&t=24296

The auto port selection and shutdown work perfectly on my Uno! thanks for that!

[dagthomas]

Im making a 50 light setup for my 30" apple screen now, so I have to do 2560x1600 screengrabs in a while - think im doomed allready. I can imagine that multiple small screengrabs will be exceedingly faster than one big grab - with scaling of the resolution maybe?

Atleast it seams its able to do 17fps on 2560x1600 as is, which is quite good actually. But it does strain the CPU quite a bit, so loosing alot of FPS in games. Good thing I just installed an extra GTX 570 in SLI ^^

[hoogerd]

I really wonder if any processing of the code is actually done by the GPU, but also still puzzled why my CPU is bored stiff (10% of a quadcore i5 and a i7-920) while the framerates drop dramatically
can anyone confirm the Processing code is done by the cpu, gpu or both?

[guyleonard]

just got home early and tried the new code, and although there improvement on the framerates, with 32bits it gets stuck at around 11fps, while with 16 bits it hits 40fps!

Am I the only one using 32bit display color depth ? viewtopic.php?f=47&t=24296

The auto port selection and shutdown work perfectly on my Uno! thanks for that!

I am running a 32bit display colour, 1680x1050 resolution, Q6600 2.4GHz CPU, 4GB RAM, Win7x64 with a GeForce 8600GT. Processing 1.5.1. Arduino Uno. Latest code from github for both Arduino and Processing. XBMC nightly + *shifty look* K-Lite codec pack.

I'm getting anywhere between 11-14 FPS response rate according to the output in processing. However, it looks perfectly fine with fast moving video and quick changes from one colour to another especially with the fade feature introduced recently (although it was fine with the previous version). In fact it looks no different from the video on Vimeo from the original Howto (not sure what the video is, though, to compare...).

Are you really getting noticeably slow response rates from the LEDs in comparison with the video your are displaying. Or do you just want a 'better' FPS for no other reason than 24 > 12? Moreover, what are you displaying? 1080p blu-ray or equivalent, 720p MKV, 480p DVDrip, youtube, general websites?

Hmm, I have just noticed in your other thread that your LEDs are taking ~2 second to change colour. Are you running the latest drivers/updated on everything? Worth a check.

[hoogerd]

thanks for the thoughts guyleonard.
I'm not happy with the low framerates because video in WMP or VLC turn into a slowmotion like video, far from smooth. I watch .wmv or .mkv HD files mostly.
The leds change quickly enough with adalight, the 2 seconds are related to the code I used from Nahiko.
Yesterday I tried it on a core-i3 laptop with on-die gpu, and framerates hit about 40, but on 1600*900 32 bit.... So I'm really puzzled why the other 2 pc's with a core-i5 and i7 that run 1920*1080 32bit drop framerates with 32bit.
Btw, sorry for spoiling this thread with my other problem; I'll continue in the other thread :oops:

[pburgess]

Hey nahiko -

Okay, added the option to do many-little-screen-grabs. Tested on a few different system configs; only one was faster this way, so it's not enabled as the default. To enable this mode, download the latest ZIP from Github, edit Adalight.pde in Processing, changing line 41 to:

Code: Select all | TOGGLE FULL SIZE

static final boolean useFullScreenCaps = false;

[nahiko]

pburgess, you are the man!!!

Anyway, how weird it is to be different from one to another computer.
I am going to download your new code, and test it.
I think I am going to quit programming my own code, and will just use yours since it has lots of options mine still does not

I give you some more feedback later on when I try everything!!

Cheers!!

[nahiko]

WOW!!!

Look at this:

Code: Select all | TOGGLE FULL SIZE

static final boolean useFullScreenCaps = true;

About 18 frames

Code: Select all | TOGGLE FULL SIZE

static final boolean useFullScreenCaps = false;

45 frames!!!