Programmatically determine the average greyscale
J. Landman Gay
jacque at hyperactivesw.com
Sun Feb 21 00:41:34 CET 2016
I like that idea. You can do the same thing in one go by applying a shadow
graphic effect to text in a transparent field.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 20, 2016 5:27:09 PM Tim Selander <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:
>> the text field crosses a blown out highlight (white hair) over to a dark
>> 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 livecode.org(mailto:hh at livecode.org)) wrote:
>>> 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:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode