Edge Detector Component

Quote
Sphinx. wrote: Why is the output not normalized? A manual post normalization step is hard to construct via FF components (or rather very inefficient), so it would be of real value if the component had this option itself.

To perform normalization, we need to have a bitmap with all output pixels already rendered - and currently Edge Detector is not a bitmap-based component (like e.g. Blur). Converting Edge Detector to a bitmap-based component would reduce output quality (pixels are inherently less precise than samples), but this is not the main problem.

The main problem is that Filter Forge doesn't render internal bounded bitmaps which are necessary for normalization - you can't perform normalization on a basically infinite, unbounded bitmap. You sort of can, by performing normalization in a certain neighborhood, but that would greatly reduce the rendering speed, in addition to the quality decrease caused by conversion from a sample-based to a bitmap-based approach.

(And another minor problem is that Edge Detector accepts and outputs HDR colors, but we could deal with it if we had a bounded bitmap to normalize.)

Quote
Sphinx. wrote: What is the uniformity parameter actually doing?

The uniformity parameter technically does non-maximum suppression step from the Canny edge detector.
The 'Fine' option produces the same result as the Canny's algorithm.
'Coarse' is a simplification - we use only 4 directions instead of 8. It reduces the number of samples needed to suppress the edges.

Quote
Sphinx. wrote: however horz/vert/direction is not possible

It's a good idea and it can be implemented easily. Maybe in future releases. I've just put it into my notes.

Quote
Sphinx. wrote: More kernel options (prewitt, scharr, costella).

When we prepared the 2nd beta, I'd almost fallen into temptation to remove all kernels except Sobel =) To my mind, all gradient-based edge detectors produce quite similar results. Maybe we'll add the options you proposed but I'm not sure.

very good to know