Programmatically determine the average greyscale

[Tim Selander]

Would it be better to do what we do in the video world? Put a 
black edge on the "Realm of Knowledge" text. Any video editor can 
do that, but you can fake a reasonable fascimile put using the 
text twice, in layers. Top layer is the text in white. Bottom 
layer in black. Shift the black text down and to the right a 
couple of pixels. Puts a black edge on the bottom-right of the 
white text. Improves readability. You can even blur the black 
text a bit to make the effect a bit more subtle.

Tim Selander
Tokyo, Japan

On 2/20/16, 11:32, Sannyasin Brahmanathaswami wrote:
>
> 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:
>
> https://www.evernote.com/l/ABHZ6MzemNNJY6SXFJ3HTMb7afCnCElhYfE
>
> 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
>
> 220,220,220
>
> at
>
> 200,200,200
>
> we start to hit the same level as the background. in this particular photo:
>
> https://www.evernote.com/l/ABFY-T8OCqNDYK4QOed3qr0G6GfqZUXWjEo
>
> For this particular context I'm actually happy with the "homeKey" field being subdued.
>
> but in other cases one wants a stronger presence
>
> https://www.evernote.com/l/ABE267idXlBHrY4Xs4ND27ziH1UjmGtU-eY
>
> Musings:
>
> 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"
>
> BR
>
> On February 19, 2016 at 11:05:52 AM, [-hh] (hh at livecode.org(mailto:hh at livecode.org)) 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
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>