Programmatically determine the average greyscale

Sannyasin Brahmanathaswami brahma at
Fri Feb 19 21:32:55 EST 2016

HH You are right of course. one pixel was an expediency and certainly does not cover all cases. In fact it is a rather weak algorithm as you can see here:  

the text field crosses a blown out highlight (white hair) over to a dark background.  

in a case like this a midtone is usually all one can decide on. in this case  




we start to hit the same level as the background. in this particular photo:  

For this particular context I'm actually happy with the "homeKey" field being subdued.  

but in other cases one wants a stronger presence  


A random algorithm also does not help us out either.  

In this "FlipBoard" model/copy-cat (which is what I'm aiming for in V1) image will be dynamically replaced on every return to the same card, not only per session, but even if the user just leaves the card and returns.  

"Only God will know for sure" what the luminance of the background will be under the field, because I'll be dynamically adding more and more images in the category over time... if we want to get really "manic" (your term ha!) we could write an analyzer to scan every pixel across the whole area underneath the field. but I worry this will take up so much CPU time, especially on Android that it will delay rendering the card.

In print we often decide to put a background frame behind the type and change the opacity of the area to give some weight to the background, but on these small mobile spaces, that just adds more noise to the design

I may settle finally on 200,200,200 for all and forget the attempt to analyze the background... though it was a very useful exercise and I have other context where I can and will use this new "skill" 

FlipBoard uses white and I guess they must have a staff of 50 people who curate every image and crop to make sure there is dark matter underneat their type... 

"not gonna happen here"


On February 19, 2016 at 11:05:52 AM, [-hh] (hh at at wrote:

> BR,  
> you do estimate the luminance of a 120x175 = 21000 px region  
> on base of the evaluation of ONE single deterministic pixel?  
> Accepted, of course, but then it may be better, from a  
> probabilistic point of view, not to take "the" pixel (40,40)  
> but *any* randomly chosen pixel of that region.  
> You could do for that:  
> set randomseed to (char -8 to -1 of the millisecs)  
> put 19+random(120) into pX ; put 19+random(175) into pY

More information about the use-livecode mailing list