10-08-2020 12:14 PM
The Raster > Spatial > Non-Directional Edge tool seems to output different results than when it is used in a Spatial Model. When you use the tool directly according to the log file it runs "sobel.pmdl". However, if you click the View button from the tool, the visual model that pops up is a different Spatial Modeler file. I am curious if there is a difference here.
In any case, my outputs are visually identical but using the Inquire tool shows different pixel values from the same operation (Tool vs Spatial Modeler workflow).
This is an issue for me because when I Clump the output I get different results. Looking for any insight here.
Solved! Go to Solution.
10-13-2020 12:54 PM
It does appear the Non-directional Edge filter GUI interface generates different results from the Graphical model that is opened from the View button. The GUI interface runs a .pmdl with a scaling that is not used in the Graphical model. I’m pretty sure a legacy Model Maker (.mdl) model or a Spatial Modeler (.gmdx) model can be modified to closely match the output from the Non-directional Edge filter GUI (if that's what you need). If you want to pursue this modification, I suggest you enter a Support Ticket to confirm the difference we observe is the same difference you are observing.
10-13-2020 02:01 PM
Support ticket opened #00069998
Thanks for the response. I'd like to pursue this in order to incorporate the Non-Directional Edge tool into spatial models. I would like it to function as the GUI does to yield the same result. An updated model that displays with you click the "View" button would be perfect.
10-13-2020 02:24 PM
Is the difference you are referring to that the Non-Directional Edge dialog results have been divided by 4, whereas the results of the .gmd in Model Maker are not?
If so that would certainly be a trivial change.
Which model do you need Sobel or Prewitt?
10-13-2020 02:32 PM - edited 10-13-2020 02:33 PM
That's what I found and my test runs show the 4X difference in output values. There are also pixel edge handling differences between the .pmdl and the graphical model that may need addressing.
10-13-2020 02:41 PM
10-13-2020 03:24 PM
Thanks Ian, when I divide by 4 in my model I get the correct result. I appreciate the speedy feedback.
On a separate note, I think it would be good to have more consistency between the GUI tools, the .pmdl files, and the other various model formats that come with ERDAS IMAGINE. As far as I can tell, the .pmdl files are consumed internally by ERDAS and are not meant for visual representation. My usual workflow is to experiment with the GUI tools and then convert a processing chain to a spatial model for automation. The models provided are helpful and definitely lower the learning curve because the Spatial Modeler toolbox is a little overwhelming at first. However in this case a simple divide by 4 was enough to derail me because I was working under the assumption that the Non Directional Edge tool and the "View" model were identical.
10-14-2020 06:54 AM - edited 10-14-2020 06:55 AM
It's worthwhile pointing out that the older dialogs which run old Model Maker / SML .pmdl models have View buttons which show representative Model Maker models (.gmd). These .gmd graphical models were only ever intended to be representative of the capabilities of the GUI dialog, not a true representation of the options chosen in the dialog.
The reason for this was that the Spatial Modeling Language (SML), which is what .mdl (model) and .pmdl (permanent model) scripts are built from, has a lot more capability than the old graphical Model Maker had (which saves as .gmd files). So a graphical model launched from the View button could not always represent what the .pmdl was capable of.
(As an aside I have no idea why for Non-directional Edge the .pmdl divides by 4 and the .gmd does not. There's no reason for the .gmd to not be dividing by 4. But I'm not even clear why the .pmdl divides by 4 - the only thing I can think of is that it was someones attempt to re-scale the results to something approximating what the input data range was. But it seems a pretty arbitrary number)
By contrast the newer dialogs which run new Spatial Modeler models (.gmdx), such as NNDiffuse, Subset, GLCM, etc., should truly represent the options chosen in the dialog when you click View or Preview and a .gmdx is brought up in the Spatial Model Editor.
Note that a by-product of the newer generation of Spatial Modeler is that you do not need to convert a graphical .gmdx spatial model into a script version for automation / batch processing - the same .gmdx is used in both instances.
And if you want to use old .gmd models as a starting point for experimentation they can be opened directly in Spatial Model Editor and converted straight to .gmdx.
There's also a wide array of example .gmdx spatial models available as starting points here:
So, short answer is that yes, as GUI dialog algorithms are replaced and swapped from .pmdl/.gmd to .gmdx you will see consistency increase.