Proof of concept. I was wondering how smooth I could get it on 8 bit leds. That´s the result today. They main key was to use look up tables with 1024 entries which are used as color palettes (avoiding any single step >1). Scaled inoise16 to a 10 bit value (0-1023) and used the tables then. Beside this I avoided any color value <3 and did some datasmoothing with the control parameters. No temporal dithering.
https://www.youtube.com/watch?v=FnRF4PE76NU&feature=youtu.be
I feel like this is the backdrop to an old Star Trek episode.
Very cool, I’ll see what I can do with it later. I like the look and feel.
I found no really convenient way yet to write the 10 bit long palettes.
Looks to be working quite well.
The code is a mess, rarely commented and needs arround 8 kB RAM. But if you like to have a look I put it on Github. So far it is just a proof of concept. https://gist.github.com/StefanPetrick/96574043d6425cc4f3ee39a2245ac965
Thanks Stefan. Wish I had time to experiment with it but am away from home for a while now. Looking forward to it later.
I´m still not happy with the waveforms of the control parameters.
Nice visualization. Yes, still a few sharp transitions. Good luck, I’m sure you’ll sort it out. 
No idea yet. It´s the already filtered and averaged noise output. Maybe I´ll stack some sine waves again and drop the idea of the noise controlled by itself.
I think I see a white whale on the horizon. Be careful Stefan.
It’ll take me a bit to get your additions ported onto my rig, but in the meantime, how well does Orange show up on this new code?
I ask because I haven’t had problems with the primary colors- Red, Green, or Blue, or any issues with their secondary colors- Yellow, Cyan, or Magenta.
It’s the tertiary colors (mix between Yellow and Red to get Orange) that are trouble. The reason is because of the rounding on the changes per step-
(0, 0, 0) [Black]
(1, 0.5, 0)
(2, 1, 0)
…
(253, 126,5, 0)
(254, 127, 0)
(255, 127.5, 0) [Orange]
Good idea on the data smoothing. Maybe try increasing it on lines 201 and 244 from 50% to 75%?
Not sure if this is worth to be ported. It´s really just testcode. Orange looks as good as we manage to describe the gardients to the 10 bit tables. It there is any interruption in the “flow” of the palette it will cause edge flicker. - edit: deleted, corrected 2 comments later - To be safe don´t blend the layers - just add them if your colors allow it. Will cause whiteish parts but this desaturation looks good sometimes.
With datasmoothing <50% I still had results like this http://fs5.directupload.net/images/170626/in9fvsqc.jpg
@Jeff_Hannan Again about orange: Now I did the math and yes - there still is a problem at the lowest end. Maybe “dithered palettes” would be a cheap solution. Like have 2 or more palettes for orange and switch between them with every frame… Sounds like a nightmare to code but I think even with my limited coding skills I could get it done. The hardest part would be to generate the proper palettes.
Palette A:
(0, 0, 0) [Black]
(1, 0, 0)
…
Palette B:
(0, 0, 0) [Black]
(1, 1, 0)
…
Did you use the same set of control parameters for both noise calculations on purpose?
It seems to me that you would want one set for each layer.
The control parameters have the same name but are filled with fresh data for both layers. The basic changes they can perform are the same but the result is different caused by different noise coordinates. The first time they depend on noise[0][…][…] the second time on noise[1][…][…]
edit: Oh, you are right, @Jeff_Hannan there is a little problem caused by the datasmoothing of the control parameters. When changing layers the old results are merged with 20 % into the new ones. Anyway, they look like shown in comment #6. Okay, maybe better to have different sets for different layers.
Not sure if it’s related, but have you seen this conversation on sharp edges in the FastLED implementation of Perlin noise? https://github.com/FastLED/FastLED/issues/416
About that alternating set of palettes- I think that is basically how the built-in dithering works.
@Jason_Coon Thank you very much, this is absolutely related to comment #6. @Jeff_Hannan I´ll see if I manage to get some testcode running. Could be a promising approach.