Atkinson dither algorithm & 'for each' loop

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Atkinson dither algorithm & 'for each' loop

J. Landman Gay via use-livecode
A few hours ago, I send a message to the mail list, a message that vanish
without trace. Now I am resending parts of that message. The rest of the
message is in the forum...

Peter Read wrote:
> One note of caution regarding the use of the "repeat for each" loop,
> whilst you will get a loop iteration for every value in the collection
> (fldhexa3 in your example), you are not guaranteed the order in
> which they will occur. This doesn't matter in a lot of cases but
> does matter when the sequence is significant.  In the case of your
> example I believe sequence is critical, otherwise the pixels might
> appear to be scrambled!

In my own setup, the control structure "repeat for each" is caching
the content of the working variable. This means that we could not
modify the content of this variable while the control structure is
working with it.

After reading your message, now I understand why this happens.
If developers are allowed to modify a variable used by a control
structure like "repeat for  each" then we could get unexpected
result as you describe: elements are processed in an out of order
sequence.

Ben Rubinstein wrote in response to Peter Reid:
> Are you sure? My understanding has always been that
> chunk items, e.g.
> repeat for each [ byte | char | word | item | line] <var> in <container>
> will always be sequential (indeed that's why this structure is fast)
> - it's only when dealing with hashed arrays that the sequence is
> not reliable, i.e.
> repeat for each key <var> in <array>
> repeat for each element <var> in <array>
> Do you have experience to the contrary?

As I wrote earlier in this same message, Peter could have found
some way to change the working variable in a repeat for each
control structure and the result is that elements are processed
with an out of order sequence.

By the way, after reading all comments and recommendations
about the atkinson dither algorithm, I wrote a new handler that
is a lot faster that my first handler, but the result STILL is not
visually identical to that handler.

My educated guess is that Atkinson dither algorithm requires
numbers with more than 2 numbers after the decimal point.
That is: 243.643578 instead of just 243.64
Later this week, I will try to discover the minimal number of
decimal numbers that this algorithm requires.

Please, check this new handler in the forum and suggest how to make
this faster and more precise:

https://forums.livecode.com/viewtopic.php?f=10&p=159078&sid=b46bc56428cb5b0f48d2c6520c107c47#p159078

Have a nice week!

Al
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Atkinson dither algorithm & 'for each' loop

J. Landman Gay via use-livecode
On 2017-10-12 19:35, Alejandro Tejada via use-livecode wrote:
> Peter Read wrote:
>> One note of caution regarding the use of the "repeat for each" loop,
>> whilst you will get a loop iteration for every value in the collection
>> (fldhexa3 in your example), you are not guaranteed the order in
>> which they will occur. This doesn't matter in a lot of cases but
>> does matter when the sequence is significant.  In the case of your
>> example I believe sequence is critical, otherwise the pixels might
>> appear to be scrambled!

Prior to 7, you had to be careful not to modify either the container
being iterated over *or* the var holding the chunk for the current
iteration as it could cause issues as described (actually, it was
fundamentally unsafe to do that, as it could result in a crash). i.e.

   repeat for each item tItem in tContainer
     replace "Foo" with "B" in tContainer -- BAD - MIGHT CAUSE PROBLEMS
     put "a' into char 2 of tItem -- BAD - MIGHT CAUSE PROBLEMS
   end repeat

 From 7 onwards, this is no longer the case. You can do whatever you want
with either the container. Indeed, in 7, the engine essentially operates
as if it was iterating over a copy of the container and with a copy of
the chunk (i.e. tItem and tContainer in the above snippet).

Upshot - you can do whatever you want with your variables - the engine
ensures that what you do won't affect what you asked for to begin with
(in particular, if you asked to iterate over tContainer, then it will
iterate over tContainer as it was at the point you first asked - any
changes to tContainer after the initial repeat for each line will have
no effect on the repeat for each clause).

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Atkinson dither algorithm & 'for each' loop

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
> Al wrote:
> Please, check this new handler in the forum and suggest how to
> make this faster and more precise.

I already gave you a method that is, with a 500x500 image, at
least 1000 (thousand) times faster than your script.

Of course this is not due my special skills but the ability of
javascript (used via a browser widget) to let the GPU/graphic
card do the essential job of pixel manipulation.

So all considerations to improve the LCS script are, TMHO, of
rather theoretical value. Here are some more:

> Al wrote:
> ... the result STILL is not visually identical to that handler.
> My educated guess is that Atkinson dither algorithm requires
> numbers with more than 2 numbers after the decimal point.
> That is: 243.643578 instead of just 243.64

Conclude from the following:
The Atkinson algorithm uses multiples of 1/8 = 0.125 for the
diffusion-error, the Floyd-Steinberg algorithm uses multiples
of 1/16 = 0.0625.

And have this in mind:
Whenever you use numToChar(Number) in your script you are wrong by
Number - round(Number) of the accumulated pixel value ...

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode