|
Leo Fernevak
Leo Fernevak
|
New upd ate in version 0.3:
The [Debug Window] has been added.
This window is useful for anyone who is interested in writing LUA-scripts for FilterForge and need to debug their code or want to know the value of some variable in their script.
First, start up the Text Window Mapscript -- v.03 (or higher):
Now, open the [Debug Simulation] script.
Here you will find this short example:
As you can see, this above script simulates a hypothetical debugging situation.
A pixel fr om a small Free Polygon is sent into the Debug Simulation, which senses it from checking the alpha-channel (variable 'a' in the script).
The point here is to set up a situation wh ere you may want to send information to the [Debug Window] which is located in the next mapscript. You can send three channels of information, through the Red, Green and Blue channels. I have reserved the Alpha channel for the [Debug Code].
The [Debug Code] is just a small user-defined 'key' which tells the [Debug Window] that you are sending three channels of debugging-data. This [Debug Code] can be anything between 0 and 1, but should be set to a specific number which is not used by the script you want to debug.
The [Debug Window] is set to pick up 9 different pre-made [Debug Codes], which are set to be easy to remember:
0.11111
0.22222
0.33333
0.44444
0.55555
0.66666
0.77777
0.88888
0.99999
What the [Debug Window] does is to scan the Alpha Channel of the [Map Input], searching for [Debug Codes]. When it finds a code it recognizes from its settings, it will store the data which are sent through the Red, Green and Blue channels, which are then sent to be printed in the window.
|
|
ThreeDee
Lost in Space
|
Ok, I think I got it now. I had to read that a few times to understand how it would be used.
If I understand correctly, you can use this pass three variable values fr om the script in the red, green and blue channels when a fourth value reaches some debug-needing stage (that you convert to one of the debug codes).
For instance, say you have variables "multiplier", "distort_amount", and "iterations" in the script and need to know which one of them is the cause of the problem when the image goes fully black at some point. Then all you need to do is make the script detect the point wh ere it goes fully black and send those variable values along with, say, 0.1111 alpha value to the output.
Right?
|
|
Leo Fernevak
Leo Fernevak
|
Yes, you are quite correct ThreeDee.
Thank you also for offering other users a good and simple example of how to use the filter.
Debugging is sometimes quite a task, especially if you have just a vague idea of where the error/s occur. Sometimes several problems converge into an error, and the sooner you can find out how the variables work, or don't work, the sooner you find what the underlying mechanisms are which leads to your problem. In my personal experience, I have in my early attempts of LUA-scripting misused 'local' variables sometimes, which could cause rather puzzling problems of seemingly functional code which didn't function properly.
Also, the script can be used if you are simply curious about the value of some certain variable, for example OUTPUT_WIDTH. I found that a picture with 1000 pixel width and height has 500 SIZE and equal OUTPUT_WIDTH, OUTPUT_HEIGHT. With this text output, you can find out more how the 'x' and 'y' coordinates work, and many other things.
My first problems with debugging was that, without some sort of debug code, your script sends return-values for all pixels in the picture, and sometimes a script can pick them up, sometimes not.
The [Debug Window] can take a few seconds to work on its normal settings, but it scans the whole Alpha-channel of the script you wish to debug, looking for any of the debug codes (for example Alpha = 0.11111). The experience I have fr om my tests, is that the debug-code is quite necessary for me to be sure that I can 'catch' the correct variables which I need to see.
In this way, you can have more control over your debugging. You can send your debug-code from basically any part of the script (inside the 'function get_sample(x,y)'), to inform you of any variable you wish to know the value of, at a particular point in time, when running your script.
Just be careful that, if you wish to send many return-values of debugging data, that each of the 'packets' have their own unique debugging-code. Otherwise, you may not be sure from which part of the code your debug data came. Presently, the [Debug Window] only picks up one debug code, and then stops scanning the Alpha channel. It will therefore only show the first debug code it finds, which depends on the x,y coordinates wh ere your debug-code was sent. These details are not extremely important, just be aware that sending many debug-codes from your script will have the effect that only ONE of them will be shown in the [Debug Window]. I could change this in an update if there is some request for such a change.
|
|
Leo Fernevak
Leo Fernevak
|
I just uploaded version 0.4 of [Text Window Mapscript].
Upd ate Notes, Version 0.4:
[Debug Window] - Certain image-sizes resulted in problems catching the debug-codes. Now this is corrected.
For those who are able to implement the update themselves, it can easily be done from the script:
I have permanently se t the variable 'xstep' = 0.005
This seems to be the best solution for detecting the debug-codes via the Alpha channel, regardless of image-size.
This above shown function can be found at the end of the script.
|
