Programmatically determine the average greyscale

[Scott Rossi]

Should have known you'd answer the same answer :-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 2/20/16, 3:43 PM, "use-livecode on behalf of J. Landman Gay"
<use-livecode-bounces at lists.runrev.com on behalf of
jacque at hyperactivesw.com> wrote:

>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
>
>
>
>_______________________________________________
>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