Maybe some sort of random sampling to define more or less reasonable color would suffice (say most popular). Random sampling, can work fast and be pretty exact for very low sampling rate

In other words, a Monte Carlo method?

How would you compute a uniform random distribution over the live* cells in a particular node**? I mean, a non-uniform method is to look at the four child nodes, choose a nonzero one randomly, and continue recursively -- but that would weight a distant block and a huge universal computer equally.

* otherwise, if you zoom out by several orders of magnitude, the pattern will become invisible since each pixel would contain a density of less than 1/k, where k is the number of samples you're taking, and therefore have an expected colour of zero.

** a node represents a 2^N by 2^N axis-aligned square of cells, where N may be sufficiently large that you don't want this to take exponential time in the value of N.

I think the color averaging can be done with a sort of "fractal method": (it's really weird, bear with me here)

I wrote a C++ program about five years ago which takes a .mc file and produces an exquisitely-coloured image according to precisely the method you describe. The brightness of a pixel is logarithmic in the density of the corresponding node.

I suggested integrating it into Golly, but Tom Rokicki didn't like the idea of increasing the size of a hashlife node from 16 bytes to 19. The difference will be less noticeable in Golly64, increasing it from 32 bytes to 35.