Okay, a new update to the diff. To produce thinner lines I took another look at the simpler Roberts Cross operator. I experimented a lot with it and it turns out you can get almost the same results with Cross as with Sobel, if you tune the threshold. Eg. Sobel 40 corresponds to Cross 10 approximately. Of course this is not the only difference as the Sobel is better at detecting edges in general (but also more sensitive to noise), but with the right settings the differences are hardly noticable. But even though Sobel requires more performance, I'm choosing Sobel, because the threshold value can be used in a much larger range in that case. Eg. you see that a 40 of Sobel is appr. a 10 in Cross, so the user would not have too much room to make Cross even more sensitive. Instead, I redefined the default value of Sobel to 60 and I have completely rewritten the filtering method.
The newest patch now does prefiltering on the viewport data instead of postfiltering the edge overlay results. This results in a much nicer image, as you will see. Of course, normally this would have needed a copy of the viewport, for which we do not have enough memory. So I just malloc space for 3 lines of the viewport in which I store three lines of filtered viewport data, and I slide that window vertically over the viewport as I am simultanously calculating the edge overlay from that buffer. So this is how I do filtering on the viewport while still keeping the memory requirement very low.
BTW, for NewbieToobie, here is an updated S3 build:
http://www.mediafire.com/?dg065o233xcsta2I hope this is better for macrophotography, since I am starting to run out of options that can be implemented efficiently with so much limited resources. BTW, I noticed that the S3 is has a DIGIC II, which is two generations older than the DIGI IV that I am testing on. So I am interested in the performance. Do you find the speed of the edge overlay usable? That would mean it is acceptable for older cameras too.
@neszt: I repositioned the text messages. They are not occupied by the menu anymore and you can read them if they are displayed.
@f_m_b:
not the complete picture is analyzed or shown
This is by design. Up and down at the edges of the screen are left unpainted to occupy less OSD, left and right are safety margins that are needed by the filtering.
What is NOT by deisgn is the assymetry. I do not understand why and how the left is larger than at right, or why the bottom is larger than the top. I suspect the latter is because the height of the viewport defined in firmware-sub lib.c is false (see sx20 porting thread), but I'm not sure. - Found cause.
Panorama:
I think the internal panorama mode of the sx20 isn't too bad. But it works although with edge detection.
Yes but not all cameras have a panorama mode.
And even the SX20's internal panorama only lets you create horizontal panoramas. With edge overlay you can also do multi-row/vertical panoramas.Why "Filter edges" is an option and is not used every time?
Because it makes edge overlay much slower and might also remove useful edges, you for these reasons someone might not want filtering. It also makes the OSD a bit more sluggish, and is not needed anyway under good lighting conditions.
Can i freeze without shooting a picture?
Not currently. Do you think this would be useful? How/with what button?
After using panorama mode the last picture is freezed. How can i release this mode back to continous mode?
Deactivate panorama and take a shot or free memory. This is not a feature, but a usability issue. I will try to solve that but currently the only way I see would considerably complicate code logic.
I cant read messages from ...
Fixed in current patch.
In panorama mode the picture freezes while pressing shutter in "ALT" mode
I'm not sure I understand. Seems fine for me. Could you please elaborate?
After freezing (pressing shutter without pano mode) sometimes the none init memory is shown for 1/2 second (horizontal bars all over the display).
Again, I'm not sure what you are seeing. I think I have seen the same thing, and I realized it was because I was pointing the camera at my monitor. It is the effect of undersampling the refresh rate of the monitor's scanline, which the algorithm detects as a horizontal edge. If you point the camera away from the monitor, it doesn't show up. Or do you have something different?
I can't reproduce the following bug. I have seen rare times that a part of the edge detection is not cleaned while moving the camera. I try to reproduce it.
Again, not clear. Why should the edge detection be cleared just from moving the camera?
It could be usefull to change the threshold with jogwheel while in edge detection mode.
Very nice idea. I'll take a look into it.
Show magnified edge detection with use of "focus lense" (AF Point Zoom = on or MF-Point Zoom = on)
Nice idea and I already thought about it and tried whether it works previously. Even though the center of screen is displayed magnified, the liveview buffer still contains the unmagnified image. So I do not know how to do this currently, as I cannot access the magnified view. But it would definitely be nice.
