Place the filter definitions in a
separate file that is included by the script at run-time.Example: An Improved Filter Kernel Script
A previous example, User-Defined Filter Kernel, described a small script that applied a user defined filter matrix to all the images in an image window. The filter we created is not necessarily a very useful one, but it produces a result that is readily seen on the displayed image. In this example, we simplify the same script and also extend its capabilities. Several changes are made to greatly enhance its versatility without adding much complexity. Here are the enhancements we make:
Place the filter definitions in a
separate file that is included by the script at run-time.
Add
two more filters and let the user choose one.
The
filter choices are displayed in a drop-down list box, from which a
filter is selected.
All
filter descriptions are stored in a table structure for use in the
main script.
The
new design is extensible, allowing new filter kernels to be
implemented rapidly and without changing the main script.
Running a script that automatically
uses images in the active Image window.
Using Include to merge a source file containing filter
definitions into the main script.
Filters are actually computed by the
included file, not just declared as static tables of numbers.
Using the CMatrix class.
Using dialogs to gather a selection
from the user.
This script uses data from the top-most image window. The script does not give the user a chance to open the selected images. Therefore, before running this script, we open an image set consisting of the image(s) to be processed. Before running the script, this When you run this script, you are first shown a dialog window requesting you to select a filter from a list:
In the dialog, click the down arrow on the drop box to show the list of available filters:
These filter names were created by the filter definition file. They were assembled into the drop box by the script. If we select item 2 as shown, then click [OK], the dialog closes and we get the following:
This script shows the user a list box containing 3 filter choices but the techniques we have used create a framework in which any number of filters can be added to the include file. This script is designed so that no changes need to be made to the main script if more filters are defined in the included filter kernel file.
Making the changes described above requires two steps: 1) creating a file containing the filter definitions and 2) modifying the main script to load the filter definition file and allow the user to choose a filter.
The first change to the previous script is to move the filter definitions into a separate file that is included by the main script at run time. The new Include file is described below. Following that, we describe how it works. View the Filter Definition File
In the script above, we first declare an empty table (a data structure to be packed in) namedFilter , using the declaration Filter={}. Then, for each filter, we define a function and add this function and other filter properties to another table namedData. Finally, to complete our implementation of the filter, Data is added to Filter using the [] syntax, which makesFilter an array we can access using a subscript. After this file is included by the main script, we can access any number of filters as Filter[1], Filter[2],Filter[3], and so on.
To add more filter choices, we would simply repeat the protocol used above. To make a filter of any type, we create a CMatrix F for its kernel, assign the filter information toData, and then set the next element of Filter toData.
It is important to note that Lua actually compiles and executes the code in the include file. This allows us to create complex filters in the included file rather than just listing a static table of numbers.
Next, we revise the main script that uses the filter definition file described above. On line 6, we include the filter definition file described above, named Include\CornerFilters.lua. On lines 8 and 9, we attach the parent window that called the script and, to be safe, test that the window is actually an image window. Lines 12 through 16 setup a dialog box containing a drop-list. The script creates a list of all filters that were defined in the include file, specifies the dialog labels, and sets item 1 as the default—compare these few lines of code with the dialog boxes shown above. Line 18 tests if the user clicked [Cancel] to abort the script. Finally, on lines 22 through 26, the script attaches the displayed image, gets its dimensions, and applies the filter to the central 20% of its area. If no rectangle is defined, Mira's is to process the entire image.
In the image window shown above, you can see from the animation toolbar that the window contains an image set of 4 images. Since the window's [p] button is pressed, one might think that all images would be processed. However, this is not the case. On line 22, the script grabs a reference to the current image shown in the window. Since it does not load any of the other images, only the current image is processed. We could, however, apply the filter too all images by fetching each image in turn inside a for loop that runs from 1 to V:Count.
Mira Pro x64 Script User's Guide, Copyright â’¸ 2023 Mirametrics,
Inc. All Rights Reserved.