Programmatically determine the average greyscale

J. Landman Gay jacque at hyperactivesw.com
Sat Feb 20 18:43:04 EST 2016


Should have known you'd answer first.  :-)

--
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



On February 20, 2016 5:38:30 PM Scott Rossi <scott at tactilemedia.com> wrote:

> A good suggestion.  You can achieve the same effect in LC without
> duplicate objects by adding a dropshadow effect to the text that has a
> size of 0, an angle of 45, and a distance of 2 or 3 (maybe higher,
> depending on the size of the text).
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 2/20/16, 3:25 PM, "use-livecode on behalf of Tim Selander"
> <use-livecode-bounces at lists.runrev.com on behalf of
> selander at tkf.att.ne.jp> wrote:
>
>>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
>>>
>>
>>_______________________________________________
>>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
>
>
>
> _______________________________________________
> 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






More information about the use-livecode mailing list