Following some dialog on this forum a couple of weeks ago I bought an easycap on the web and downloaded virtual dub for capturing to make a first foray into video astronomy DSO imaging. After some tribulations similar to others I eventually got the easycap working (I have Windows 7 and the driver supplied on the CD didn't work so I had to find and download and further update another driver). I had a bit of bother with virtualdub as well but now that is sorted out as well. The residual issue is that the W7 easycap driver does not permit capturing frames at anything less than the full 25 frames/sec PAL rate.
I can persevere with that and manually delete duplicate frames from each capture prior to stacking (next step in the learning curve), and/or do a workaround by making the capture time and capture file size limits very low compared to the integration time I am using in the camera to limit the number of duplicate frames in each capture.
A question that occurs to me is: what is the optimum integration time for image quality? I notice that many people seem to use the GStar at its maximum 2.56 sec integration time and do X captures (unique frames): is that better than say using 1.28 sec and 2X captures (or some other rule of thumb) instead, or going for about 5 sec (on my Stellacam3) and X/2 captures?
There is presumably a trade-off here, and I see people varying the 'X' quite a bit for different objects, but not using other than 2.56 sec integration time much if at all. I can imagine making the integration time too long will mean the individual frames will have bleeding around stars etc, overexposure and movement from imperfect tracking, but is there a lower limit? Maybe at that end of the scale, very short integration time means too many captures i.e. too much work.
Can anyone who has experimented with this offer advice?
I use a GStar on an LX90-8" in Alt-az config. The mount does not have all that great tracking ability. So the GStar gets put in the shortest accumulation time I can manage.
That means - if you can see a dim fuzzy in real time at 128x, then try at 96x ... etc.
The downside of this is that the video stream is only an 8-bit signal, which means you need to keep up the accumulation time or the image starts to posterise if it's dim. In layman's terms, you don't have enough of a difference between brighter dim things and dimmer dim things, so they end up looking the same, and when you try "stretching" the region in Photoshop to bring out the subtle bits ... they're just not there.
The bleed around stars is another phenomenon, and some imagers take a "starfield" image or series of images, at a much shorter acc rate, and layer that into their final image.
Be aware that I am still learning all this stuff.
You may wish to read Steve Massey and Steve Quirk's excellent book, "Deep Sky Video Astronomy" for a more in-depth treatise on the subject.
But basically, I only ever use max. integration while framing the image, then I drop back to say 96x for deep sky work.
Setting the AGC slider to just to the right of half way will make your final image come out a lot smoother.
Is there any reason you're not using the G-Star capture program?
I went through the same as you, when I couldn't get Easy Cap to work, having to delete duplicate frames, it can take all the fun out of processing.
I now use a Belkin Video capture device, it takes higher resolution images and has no conflicts with G-Star Capture.
Software supplied with video capture boards is usually pretty useless for Astronomy. Try the AstroVideo.,30 days free trial. You can specify any exposure time from 1 millisecond to 1 hour. Software automatically subtracts dark frames and aligns and stacks the images on the fly.
Thanks to those who have responded to my requests for advice on video capture, and sorry for my late response - I have been away. After some trials with easycap and virtualdub I agree with Jeanette that manually duplicating the 99% or so of redundant frames is too tedious, and since it seems easycap itself (at least the one I received) is incapable of recording at less than the maximum 25fps rate, I will also change horses and get a Belkin device.
Jeanette, I went for virtualdub because that seems to be what those who had been successful with videocap were using. I no longer have any strong reason to prefer it, but having said that the software seems OK based on my limited experience. I'm not clear what the GStar software offers that virtualdub doesn't (noting that I have a Stellacam3 and not a GStar) but I guess I'll find out. Karl, AstroVideo also sounds like a good option though at some purchase price.
Jeanette and Tony, thanks for your insights on the actual DSO capture process - I had assumed leading from my own visual use that if an image had good fine detail in the monitor say at 128X that the camera would be recording that detail sufficiently at greatly lower integration rates (such as 8X) even though I couldn't see it on the screen, and only needed stacking and processing of an equivalent number of fresh 8X images to bring it out. But it seems from my limited practice that stacking say 120 such unique images is nowhere near as effective in bringing detail out as increasing the integration from 8X to 128X; ie. a relatively high level of integration in the camera itself (say 64-96X or so, or more for faint objects) is still necessary as a starting point. In other words, you need to be able to more or less see on the monitor what you are going to capture. Let me know if you agree or not with this.
Another thing that has just dawned on me; the 128X (for example) that GStar and probably Stellacam quote as taking 2.56sec must signify half frames rather than full ones, since 25fps*2.56s = 64 frames.
Video streams (PAL ones anyway) must operate at 25 fps. That's how AV works. An integrating video camera still shoves out images at the same 25 fps, except that they only change every n frames according to the integration rate. The easycap, or belkin act only as an intermediary - they will always work at that rate.
It's your video capture software that needs to be set to capture only the n'th frame. If only to reduce file sizes. Multiple 'same' frames won't harm your image stacking, it will just take longer to process.
VDub can change the capture framerate in Capture, settings.
GSTAR-Capture has been specifically designed to make it very easy for Gstar users, but works for all other devices too. I can't recommend it highly enough.
And yes, the GSTAR operates using fields (half frames), so your calcs are correct!
When I tried a couple of weeks ago now to set virtualdub to less than 25fps in file>capture AVI>capture> settings, it would not accept the change, always reverting to 25fps.
I asked questions on the web, and was advised that some capture devices (ie. the hardware plus driver software) could be set to operate at less than full framerate, and some (such as mine presumably) could not.
Are you absolutely certain that all capture devices and their driver software can only output at the full frame capture rate? If so, maybe GStar-capture will do what I want. I fully understand that PAL cameras themselves output at 25fps, but the evidence seemed to suggest that the problem was in virtualdub not being able to control the capture device in my case. I was able to work around this to a degree by limiting the capture time to 1 second and the capture file size to a couple of MB in virtualdub, but that meant a lot of manual work joining AVIs, which was a pain.
I will give the easycap/GStar-capture combo a try before abandoning easycap altogether, but I would be interested to hear further from you on this. My understanding is that the capture device is an A to D converter, so the output from it is no longer an analog PAL video stream but a set of digital AVI frames.
On the question of redundant/same frames not harming the stacking process, I agree with you; it is just the enormous multiplier effect on the number of frames that would have to be stacked to get the same effect: to stack say 100 'distinct' frames at 128X integration (derived from 100 x 2.56 second streams) would require 6400 'mixed' frames which would therefore take 64 times as long to process.
I have enclosed an image of the setting at .3 fps off my normal usb webcam. If you press the highlighted button, you get a selection of standard framerates too.
It really is nothing to do with the camera or capture device. It's only sampling the input stream. The very fact that you are getting an image sugests that all is relatively OK.
Sadly, video can be a quagmire to set up. 90% of the time there is no issue, but...
Prove to yourself that it actually works by using Gstar Capture, and if you want to go back to VDub, then we can do some more troubleshooting. In the unlikely event that it doesn't work then we can try changing the driver you use - often using the VFW in the device list is better than the specific device.
Most webcams are spec'ed for simplicity and consequentely fps is a off-shot to provide automatic adjustment for quality and reliabilty. The more expensive specific cameras are design to have a load of user input to acheive maximum FPS.
Webcams are design to be sold in the millions and it would be off-putting to consumers if they had to fiddle about to get the right settings.
Thanks for the offer Jonathan - will try GStar capture.
Malcolm - I didn't really understand your comment: what is an off-shot? I am not actually using a webcam, and the issue is sampling low fps (on DSOs using an integrating analog videocamera) rather than high fps.
Just to tidy away this discussion thread for the possible benefit of others in the same situation, I downloaded the current version of GStarEX Capture and lo and behold, it worked in conjunction with Easycap including most importantly the ability to limit capture frame rate to as slow as I wished (in this instance 1 frame per 10 seconds), which for whatever reason virtualdub would not allow (only 25fps possible), and I managed a quite reasonable stacked image of the Sombrero as my first result.
So in summary, Easycap + GstarEX capture V3 + Stellacam3 allows variable capture frame rate.