Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_dslr_mirrorlesss_winners.thumb.jpg.9deb4a8db27e7485a7bb99d98667c94e.jpg

HenkSB

New Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

9 Neutral

About HenkSB

  • Rank
    Nebula

Profile Information

  • Location
    Santa Barbara USA
  1. HenkSB

    Rosette

    Ugh I found out that I stacked the image wrongly from what I thought were raw TIFF files unfortunately they were processed. Here's a much improved version. It's an old thread but I felt frustrated about the results and wanted to show the improvement.
  2. HenkSB

    Rosette

    I added another version where I did not use darks. It was much easier to edit. Perhaps the temperature was slightly higher when I took them? I also edited the RGB curves individually. This is more like what I had in mind. The blue stars are not controlled well, I did not attempt to fix that in Gimp.
  3. Reading that link again there is actually no reference to a QHY5 just "USB camera" so I must have had the links in my head messed up. Nevertheless if anyone knows an OpenCV or v4l2 driver for QHY5 I would appreciate it.
  4. (BUMP!) Sorry to bump this but maybe I started this thread at the wrong time being not in the mainstream SGL continent. I noticed a good deal of Linux/RasPi savvy posts on here so please chime in. Maybe I should have picked the DIY forum? Anyway what I found meanwhile is that QHY has published a Linux SDK on git but no source code. Even then, their API does not seem to have anything to do with v42l or OpenCV. So I am still puzzled what supports the Python code in that link. Any help appreciated, thanks again.
  5. HenkSB

    Rosette

    Thanks Goran. I doubt if the Fuji is causing that, it is diagonally and I've never seen that before. More likely it is some guiding artifact in RA since that' s the direction of those bands. It can be made to go away at the cost of detail in other parts of the picture. The quality of the data is simply not good enough for a real nice picture. I will try again next year and maybe have SGP running so I can image on multiple nights.
  6. Here's my Rosette from last night: ES17CF on AVX with a Fuji X-a1, 150x56 second lights, 54 darks, 26 flats, DSS, Gimp 9.3.1. In editing I only changed the value curve and did not mess with the color. It's pretty red! This is as much as I could squeeze out of it and honestly I expected it a bit more for the work. I suppose a modified DSLR would be quicker. Thanks for looking and clear skies.
  7. I want to use my QHY5 with OpenCV on the Raspberry Pi. From what I know so far OpenCV supports v4l2. So if the QHY5 driver is a v4l2 driver it should work without a problem. But it does not. Looking at the PHD2 code I see that it is used with the plain libusb API, so perhaps the QHY5 driver is a plain USB driver but not a v4l2 driver. The device is listed as /dev/QHY5 while I suspect it should be /dev/video0 because v4l2 is a video driver. Yet, I have seen Python code (at http://sy2000.blogspot.com/) that uses the QHY5 with OpenCV happily, unfortunately little was said about the driver. Any suggestions? Thanks in advance.
  8. Actually the reflection of the secondary will generally not be centered on the focuser axis; the faster the scope the more it will be off. For a detailed description with pictures check Don Pensack's article http://www.catseyecollimation.com/pensack.pdf . Collimation is an iterative process. If you started out centering the secondary by adjusting the main secondary screw as the first step showing all primary clips, eventually you may have to re-adjust it again as a result of angle changes using the secondary adjustment screws. Most important is the alignment along the optical axis though, which you seem to have achieved.
  9. Hello and thanks for having me. I am from Santa Barbara, CA, an orange zone where the skies are often clear and where we badly need more rain (and are finally getting some)! I have a Z12 Dob that I converted to a collapsible truss model, a 10" Coulter Odyssey Dob that I started out with and successfully used for AP on a DIY barndoor drive (dual axis, autoguided), an ES127CF on an AVX, a Venture RX-7 127 mm Newt, an SSAG autoguider, a Fuji X-a1 camera and a DIY EQ platform for my Z12. For editing I use DSS, WLPG and a 32-bit Gimp development version. Cheers and clear skies!
  10. Hello Matt I processed your last TIF in DSS and WLPG and pretty much got the same result. With 6 hours of data it ought to be much better if the seeing is reasonable, IMHO. For instance, I tried M45 once with a cheap 300 mm Sigma lens with 17 x 56 second images at 6400 ISO and got a better result. To rule out the obvious, I presume you are stacking raw images, right? I can imagine JPEGs washing out all the details. Looking at the washed out results my first thought would be dew especially since the bright parts of the image are affected more than the rest. Did you check for it? Poor seeing can wash out the results too but that would be equal over the entire brightness range. Not much you can do about that. Light pollution will also affect the image but it should not wash out the detail if enough data is available (such as 6 hours). When turning up the contrast I noticed a cross hatch pattern throughout your image. I don't now your location but if you live near London I can tell that the main lines are perpendicular to the RA direction according to Stellarium. There is a slight elongation of the stars in that direction as well. So the tracking is not perfect, did you autoguide? If not it could be due to polar misalignment or periodic error. For 5 to 10 minutes it is small though. I can't think of any reason why that cross hatch pattern would occur since tracking issues should affect the image equally everywhere. If it is a diffraction effect it has nothing to do with tracking errors. I have no clue what could cause that. The red halos around the stars are indeed probably due to CA from your zoom lens. I don't think your problem is not so much image processing but the data content. I wonder if artifacts would show up more clearly if you too shorter exposures at higher ISO. Doing that should be OK if the camera can handle that ISO so long as the exposure is short enough to not wash out the stars. It also depends on the DNR curve of your sensor. May be worth a try, I don't think you need 6 hours to tell the difference. Sorry I can't help much, hope some of these thoughts may help.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.