reedsturtevant wrote:A software guy! Excellent!
LewisASellers wrote:Whether or not the hardware is physically positioning each sucessive frame ... it's a good thing if the software can.
If you can find the frame line in software that may be the true reference to stabilize for...in a sloppy camera the perfs will be jittery but the image of the gate itself should be fixed in relation to the camera optical system (apart from breathing along the optical axis I guess). But you probably already thought of that.
Well, as time permits I'm building a complete replica of Eric's machine to work on the software driver issues. I'm not a hardware guy though (that's more along Eric line). I'm not all that worried about it being too off the mark but in this medium even a pixel or two is noticable.
Yes, like you said. The current strategy on the matter is to detect both perfs and frame image. The perfs aren't as useful as I was more naively thinking they would be, but they still have some use detection wise as a crude "guide" or hint, simply because they're such large uniform targets.
I'm a little paranoid that without it, that in certain (rare) lighting circumstances it might not always be entirely clear where the exposed frame area is, and the auto-detection otherwise might choose a slightly off area.
It's somewhat overkill perhaps, considering the machine, but I also migrated in a deskewing algorithm originally designed for correcting photographic flatbed scans on the Windows platform.
Of course, you can always use crosshairs and choose frames manually but .... that's a lot of work that only say a stop motion animator could love. /-)
LewisASellers wrote:
Also, are you working high-dynamic-range (HDR) ideas into your system? Just curious...
viewtopic.php?t=9139
The software at the moment (v 113) does not use HDR. However ... ... it is about to move that direction within the next 3 or 4 builds (rough guess). Eric has been pushing to get OpenEXR and Cineon support, etc added in. It's in my to-do list. But there's just so much to do first. (I've been changing the source code of late so much from day to day that's it's become rather difficult for Eric and I to colaborate at that level on it easily at the moment. I think everyone involved is getting a bit "fried" at the moment.)
If you're asking, btw, if it will be able to compose several photographs/image into a higher-range ... I hadn't considered it, by why not. As long as I can find the math equation, an algorithm, some psudeo-source code or a clear explaination of how something is suppose to work, actually coding it isn't much of an issue. (The hardest part of programming is talking to other people's 3rd party software or APIs.)
Anyway, ask Eric about it for more details. But the answer to your question however is yes, just not this second. (But ask me again this time next week. /-)
