From: "niborl2000" Date: Fri Sep 27, 2002 4:10 am Subject: AstroVideo 1004xJG USB exposure errors Hi all, I have my Jon Grove 1004x PCI to USB conversion logic board on test and I am finding significant errors in the exposure timings produced by AstroVideo. The program countdown timer runs correctly. But because the twain capture program has to start and make a run before the capture can take place, the actual exposures (as checked by listening for the relays opening and closing can be significantly longer. In hi resolution mode, where two capture sequences are required, the errors are even greater for the second half frame. I am running XP on a 400Mhz machine and get the following actual exposures for a nominal 10sec exposure low resolution and first half high res 13.7-16.0 sec second frame hi resolution 21.5 to 27.0 sec In hi res mode the difference in exposure between alternate lines is obvious in the final image. Does anyone else see this problem? Clear Skies, Robin From: Jon Grove Date: Fri Sep 27, 2002 4:34 am Subject: RE: [QCUIAG] AstroVideo 1004xJG USB exposure errors Hi Robin, Timing with the USB capture is a problem. The time taken to grab an exposed field from the camera totals about 3-4 seconds, made up about 50/50 from the time taken to start the capture dialog and the time taken to download the captured image. It may be possible to improve the exposure accuracy of lo-res captures by starting the capture dialog early, thus avoiding the first part of the delay. However I can't see a way to avoid the delay between capturing the two fields, unfortunately. iCatch compensates for the different exposures by attempting to match the histograms of the two fields, which does a pretty good job of removing the interlaced look whilst retaining the high resolution (however that's not much consolation to you at the moment, since I know you have problems getting iCatch to work!) In an ideal world we would be able to put both fields into a single frame and capture it in one go - but unfortunately there is no suitable signal from the USB device to allow this, and the best that can be done is to grab one field at a time. Also it would be really nice not to have to load up the dialog every time, but we are forced to use the interface provided by Hauppauge/Zoran/Nogatech, which insists on popping up the dialog when asked to do a Twain capture. It's very annoying, but short of writing something that communicates directly over the USB, I'm not sure what else can be done. Cheers, Jon. From: Bev M Ewen-Smith Date: Fri Sep 27, 2002 7:57 am Subject: Re: AstroVideo 1004xJG USB exposure timing Hi Robin, You are quite right that the Twain capture operation takes a long time (depending on the performance of the machine) to crank up and actually capture the images. I think your times may be worse than those that I have seen but the effect is certainly there. In fact, having noticed the effect, I already preload the Twain driver before the image ends to try to minimise the duration. Beyond that, there is nothing I can to do to shorten the capture. It is really down to the Twain driver itself (Not guilty, m'lud). What would you like me to do about the absolute exposure time? In principle, one could reduce the calculated time by the mean observed capture delay but this seems a bit tacky and you could do that anyway by putting in a lesser exposure time. What I *am* working on is a tool to equalize the alternate lines in the high resolution mode to take out the effect. This is much less trivial than it sounds because there is an offset and gain difference and, even worse, some non-linearity (gamma) to try to match. It is not simply a matter of linearly scaling the even lines to match the odd ones in the light of the actual exposure times (which we do know). Thanks for being patient. Regards Bev From: "niborl2000" Date: Fri Sep 27, 2002 12:21 pm Subject: Re: AstroVideo 1004xJG USB exposure timing Hi Bev, As long as people are aware that exposures are increased by their own system processing time, I don't see the exposure length as problem. I would guess it might explain Etienne's startling 2sec exposure results recently though. As you say, potentially more of a problem is the uneven exposures of the two fields. I see from Jon's post that he has tackled this in iCatch, but I have not evaluated it yet. Averaging frames would help, but with people moving to pixel accurate guiding and stretching histograms to the max, I would guess adjusting the two field exposures will still be important to avoid graininess. Anyone know of a cheap software controlable shutter mechanism? Robin COAA From: Jon Grove Date: Tue Oct 1, 2002 5:50 am Subject: RE: [QCUIAG] Re: iCatch - yet another version! Hi Robin, That's a possibility - it would depend on whether it's possible to synchronise the camera releasing the exposure with the particular field that the USB device is grabbing. I think that in streaming mode it only uses one field per frame (but I could be wrong). The camera is able to output either set of scanlines (or both, binned) in either field, depending on the timing of the signal on the PP. My gut feeling is that the USB link and software will introduce delays that make timing a bit hit-and-miss, in which case we'd require some extra circuitry to ensure an exposure was only released on, say, an odd field. But it's probably worth a try! Jon. > -----Original Message----- > From: niborl2000 [mailto:robin@leadbeaterhome.fsnet.co.uk] > Sent: 01 October 2002 13:02 > To: QCUIAG@yahoogroups.com > Subject: [QCUIAG] Re: iCatch - yet another version! > > > Hi Jon, > > Etienne's streamed 320x240 images do not seem to show much sign of > compression problems. I wonder if a VFW streamed aproach to lo res > long exposure capture like the PCI version rather than using twain > might run faster, particularly when self guiding? > > Robin > > > Hi Robin, > > > > That's a good idea - I'll have a think about putting it into the next > > iCatch. Maybe it could switch to that way of working if you specify > > a zero-length exposure or something. > > > > It's annoying that there seems to be no support for 640x480 streaming, but I > > suppose that using Twain would at least give the benefit of uncompressed > > images. > > > > Cheers, > > Jon. > > From: Bev M Ewen-Smith Date: Wed Oct 2, 2002 2:26 pm Subject: 1004-JG-USB Hi-res mode in AstroVideo Somewhat belatedly, I have added an "Equalize odd/even fields" option to the High resolution capture mode of the 1004-JG-USB version of AstroVideo. It processes out the artefact that appears due to the odd and even fields having slightly different exposure times due to the Twain driver latency. The tool can be used free standing (post-capture) or automatically at capture time. Version 2.5.6 is available from www.coaa.co.uk/astrovideo.htm Regards Bev COAA From: Jon Grove Date: Fri Oct 4, 2002 12:52 am Subject: RE: [QCUIAG] M31 with SLR lens and 1004x... Hi Ray, > Jon, I had problems with 06 iCatch, the images capture fine but don't > display on-screen until I click to do another! Then only for an > instant. 3 seems fine. > In iCatch 06 I've decreased the number of windows that it keeps open, to prevent the desktop getting so cluttered. Whilst capturing a series of images, the last snapshot should always be displayed in the window, but when you stop imaging (either because you hit the 'stop' button or because it captured the requested number of images) then with the PCI version of iCatch the window will either retain the last image or switch to live video. Which of these happens is determined by the 'preview' and 'overlay' menu options - if neither is selected then the snapshot should be displayed, otherwise you'll get video displayed using the appropriate method. At least, that's what's meant to happen! HTH, Jon. From: Jon Grove Date: Fri Oct 4, 2002 1:19 am Subject: M31 and M45, 50mm camera lens Nice and clear last night so I decided to have a go at M31 using a 50mm SLR camera lens. It wasn't mounted quite perpendicular to the CCD so I couldn't get a uniform focus, but it wasn't too bad considering it was all held together with bits of black tape! I used an IR block to help combat chromatic aberration, and a sodium block because I was at the front of my house in the full glare of a streetlight. I piggybacked the camera on my Europa+GEM, and took a bunch of 20 second exposures. Longer ones didn't seem to bring out much more, because of the light pollution I suspect. I then noticed that M45 was creeping out from behind a tree, so I snapped some 10s shots of that too - managed to capture some of the nebulosity, which was pleasing. Had a look for NGC891 but failed to find it - the streetlight shining in my face made it hard to see where I was looking through the finderscope. Still, here are the results, hastily processed last night. All the images were captured using iCatch_PCI 0.06, in hi-res mode. I had to shrink them during processing to tighten up the stars, which were a bit bloated probably because of poor focussing and chromatic aberration. I couldn't see Polaris from where I was, so had to guess at North - as a result there is some field rotation visible - but I'm pretty pleased with the results. Certainly they're the best I've had from an SLR lens, I think the IR filter made a big difference. Clear skies, Jon. From: Jon Grove Date: Thu Oct 10, 2002 1:48 am Subject: iCatch 0.07 Hi all, Wilfried Wiehler drew my attention to a bug in iCatch_PCI 0.06, which caused it to save invalid AVIs under some circumstances. I've uploaded a new version onto my page which fixes the problem. http://www.geocities.com/jgroveuk/iCatch.html However be aware that if you select certain video formats and screen colour depths, it is possible that iCatch (PCI) will save 16-bit AVIs. This is undesirable since we are dealing with greyscale images which will have unpleasant banding effects when represented as 16bit RGB. If you use the PCI capture card, you really need to ensure that it saves in 24-bit mode to be certain that you don't lose information. A reliable way to ensure this is to capture in 24-bit and to have your monitor set to at least 24-bit. However other combinations may work too, and may be beneficial if you have a lower specification machine. Most of the video formats preserve the full 8-bits of luminance, with the exception of 15-bit or 16-bit RGB. If you can find a compressed format which still produces 24-bit AVIs then you should be OK. To test the bit-depth of the AVI, generate a 1-frame AVI and calculate (8 * filesize in bytes)/(image width * image height). The nearest integer should be the number of bits per pixel. Jon.