@BR
I adjusted your function a litte bit (and it works now here).
There is a new parameter for testing the upper/lower half
of the image (this param = empty tests the full image).
The mouseUp is my suggestion for a first testing. On base of
these two values you could develop a decision rule for a
@ HH
OK I will "bite" on your idea. but I have never examined or processed the
imagedata. Please scrutinize my code below. But there is a major caveat with
your original code (see below)
I think I got it correct.
but there is a huge difference on the result between the 1 X 1 and the 12 X 9
There is still one option that uses a weighted grayLevel-mean
(I use these weights in imageJIT). This would reflect more
than simple averaging that one wants a dark/light decision.
return (0.1*byteToNum(byte 2 of iData) \
+ 0.6*byteToNum(byte 3 of iData) \
+ 0.3*byteToNum(byte 4 of
@ hh
That works!
fascinating. Though what is bright not bright, is, as you say, "not sharp"
Images that return a value > 100 still seem bright enough to warrant darker
type…
and of course you may have e.g. very dark stone mountains (taking up 1/3 of the
composition space at the bottom half
> So is there a fast, efficient way to analyze a 1200 X 800 px
> image to get this average brightness value.
You could try the following function. It is "dirty" (the definition
of 'brightness' is also unsharp!), but it is very fast.
local ii="tmp-1.414214"
-- uses the average color intensity of
Hi Sannyasin,
Based on my previous experiences trying to process
images with LC pixel by pixel, I would have to say no.
LC is too slow for this kind of processing.
You would probably have to use a routine written in
some other language like Objective C, or C++, etc.
If anyone else has had a
Use Case:
I want to place puzzle tiles on top of an image. We take a field, put a grc
behind it, take a snapshot, crop each word off at -1000, -1000 and then
scramble the tiles to make a puzzle… all this works really well. So I decided
to dress it up a bit more: we dynamically choose a color
