An observation:

Traverse the flames in this order:

   outer top, outer right, outer bottom, outer left
   inner left, inner bottom, inner right, inner top

If you number the flames starting at 1, then every even numbered flame's length produces this consistent pattern all around the image:

0 1 1 0 1 1 0 1 1 0 1 1 ....  (short = 0, tall = 1)

The 011 pattern repeats 25 times but only for the lengths.

The odd lengths (the bits between the 011 pattern) seem random and all color bits seem random too.

So the information encoded in the lengths cannot possibly be part of a private key (at least not the even numbered ones). 

This suggests to me that the bits of the private key have been interleaved in the inner/outer colors of the flames.  Perhaps the pattern is there to indicate how to rearrange the bits back into order?

Also note that if you take the first 6 lengths of the outer top in this
order:

 2 4 6 1 3 5

You get: 0 1 1 0 1 0

Which is the same pattern we see in the lengths of the 6 ribbons in the image. (2 4 6 5 3 1 would also work)  In fact, the ribbon pattern also has the 0 1 1 pattern for it's even numbered ribbons.

This suggests a length of 6 is significant.

I count 456 bits of information in total (98 inner flames + 54 outer flames each flame carrying 3 bits of information : length, outer color, inner color)

But 456 bits is much more than is needed for a private key.  You need either:

 1) 256 bits for a raw key; or

 2) 296 bits for a wallet import formatted key (uncompressed); or

 3) 304 bits for a wallet import formatted key (compressed)

If we omit the pattern which we know can't be part of the private key, that leaves 380 bits.  However, the color encoding part contains 304 bits which is just enough to encode 38 bytes (the right number for an compressed wallet import formatted key). 
 
My guess is the lengths are there to show how to un-jumble the color bits back into place.