Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

bomberbaz

Members
  • Posts

    5,232
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by bomberbaz

  1. 2 hours ago, ollypenrice said:

    I think a good gradient removal tool would flatten your M81 if you just stacked it without flats.

    Olly

    It's fine really olly, the data wasn't the best and losing it doesn't bother me. I am spinning enough plates as it is.

    However thinking about it, nothing wrong with having a reserve project to learn more about. I shall recover the data to my back up drive and  have a go.

    My processing skills need improving, so maybe use this an an opportunity to learn something new!

    • Like 2
  2. 6 minutes ago, tooth_dr said:

     You cant be sure if a flat is bad by looking at it, it can look awful but as long as it corrects the data properly then its good!  Unfortunately the fresh batch of flats wont be any use for the lights above but it's always better to have clean surfaces as much as possibe.

    I have got to the bottom of this in another thread.  It was a comedy of errors on my behalf but thankfully with the help of other peoples input and hindsight of the mistakes it has now been sorted out.

    The main error above is a variable level output from a tablet being used as a whitescreen, that is what has led to the uneven image results. A sheet of white paper and a slow rotation of the tablet  device evened out the flats and the latest results were significantly improved.

  3. Thanks Guys, especially @ollypenrice but all who chipped in. I have had to bin the M81 data, various changes to the camera chain means I am going to struggle with it and simply cannot be bothered with it now.

    However the M3 effort below is a little over 30 minutes worth, which has only had a simple stretch is how I know it should look from my garden. Gradient right to left from the hotel car park lights across the road.

    I re-did darks, dark flats and flats. Flats done as per advice from Olly and Jacko, results speak for themself. 

    cheers

    steve

    testM3.thumb.png.0c881e733161bcf174c54e64f0c66840.png

    • Like 3
  4. 21 minutes ago, ollypenrice said:

    Flats are simply photos of the incoming beam as it hits the chip, which means they all have more or less the same form with only the dust bunnies varying. Neither of your posted flats take this form. The first one is closest because at least it has  a bright centre getting darker towards the edges. However, it doesn't look credible.  The bright inner circle dims with unusual suddenness and then there is very little further drop-off into the corners. There is also a bright band running upper left corner to lower right corner. The latter cannot be genuine.

    The second flat is flat - too flat to be credible. Not even my TEC 140-with-flattener is as flat as that and it is corrected for medium format film.

    What we then notice is that the illumination of the second galaxy image closely resembles the illumination of the first flat, with the same bright inner circle dimming quickly to a very even outer region. My conclusion would be that the second image has been largely unaffected by the second flat, which is to be expected since the second flat is so flat as not to change much when applied. This suggests that the first flat was on the right lines regarding the general illumination but had irregularities of its own in the form of the bright diagonal. This bright diagonal has influenced the second image.

    What might be worth a try would be this: Set up the rig as it was for the first flats but, during capture sequence, rotate the screen continuously. It doesn't matter if its moving when the exposure is made because you're not trying to image the screen itself. When stacked, this ought to average out any screen irregularity.  Alternatively, just try a different light source. I'm pretty sure you present one isn't even.

    Olly

    Thanks Olly, that all makes good sense.

    Just a quick question of you, would a massivly out of focus affect the image being received, as it was a very long way out of focus for the 2nd flat and I only realised this last night. Schoolboy error.

  5. 1 hour ago, Clarkey said:

    When was the first flat taken? I have had similar gradients which I could not fathom out with my Rising Cam IMX571. Although I never found out for definite, I think it was dew. Since getting a new heater strip for the camera and turning the internal dew heater to 'max' it has not been a problem. Your issue might be something completely different - but it is the best I can come up with.

    Thanks for the reply, these were taken Monday, the scope was dry when I brought it in, no evidence of dew.  I am completely baffled but one thing 9is the scope, an ED72 is new so maybe a visual session is needed to rule that out as a problem. That said, the problem seems to me at least to revolve around the calibration frames.

  6. I ordered a ZWO single filter drawer from FLO and a spare filter holder. For those that do not know there is a V1 and V2 drawer, but they are not compatible with each other. (I did not know any of this either)

    So the upshot is my V1 spare holder wouldn't fit into my V2 drawer, so I pinged an email over to FLO and asked if I had made an error. I knew I had but didn't know "how" I had!

    Next thing is an email from FLO apologising saying their site should be clearer about the V1 / V2 thing, also that a V2 replacement was posted out free postage, finally a return label was emailed to me to send the other V1 version back to them. 

    Absolutely first class service guys, above and beyond expectations there. 👍👏

    • Like 4
    • Thanks 1
  7. Ok so yesterday I put up the top image showing the wavey gradient and so now I have also attached the accompanying master flat. This FLAT is 0.16 seconds, just the tablet screen dimmed and laid over the top of the scope.

    As you can see quite uneven and suggested to be the reason for the poor image which seems feasible. The tablet screen not giving an even glow being my thought.

    Next the new image and flat (also below) showing the central region blown.  The accompanying flat though seems decent. New flat 0.9 second, two pieces white paper and a brighter screen on top. Histogram at 50%

    The base light data is the same for both and yes the flats are in the right order. Stacked in ASTAP.

    What is going on here, I am mystified!

    m81testoldflats.thumb.png.2aa4e36fa47eb91115b78828d7a1b210.pngFlat_160.0ms_Bin1_183MC_gain115_20230425-174344_0011.thumb.png.51d0579649895f73f245635fd7c0d672.png

     

    This is the second batch using the new flats. 

    m81testnewflats.thumb.png.dcba91f0a2d5290849f4525563791aa2.pngMasterFlat_Gain115.thumb.png.1b513111eaeeff36d00440dbb478126c.png

  8. 6 hours ago, tooth_dr said:

    The background looks odd, like the flat calibration isn’t correct.  I’m not sure what camera you used, some OSC are harder to calibrate.  When I calibrate my own OSC data it either has a completely flat background or just a simple gradient running across it if imaged during the moon.  If you can sort this issue it’ll make processing 100x easier.

     

    2 hours ago, alacant said:

    Hi

    Guessing: There may be cloud on one or more of the frames? Light entering the telescope? Condensation? Non-corresponding flat frames? Difficult to say without more detail, but easily fixed. If you corrected each frame before registering and stacking, even better.

    I used Siril, but I think ASTAP may have something similar.

    Cheers and HTH

     

    Just looked at the L2 filter, there is a smudge print on it, might be the problem or it could be the lights although they are new ones. Think I shall start again, clean my filters with some isoprol, blow out the focal train for dust and do a new fresh batch.

     

    EDIT> The flat fit below explains it, very bad indeed.

    Flat_160.0ms_Bin1_183MC_gain115_20230425-174344_0011.fit

  9. Hello all.

    Just a very brief overview of a comparison I did for no other reason than I had a few minutes to kill.

    There is only a small amount of data (about 30 mins) on M81 at the heart with M82 and NGC 3077 off to upper sides. 

    The images are messy but these are purely stacks including usual calibration files, I have done nothing else to them so I just thought I would stick them both up.

    DSS is well known and simple to use, ASTAP is a little more involved but none the less not too difficult once you learn how it thinks!

    Top one, DSS, bottom ASTAP. I would welcome opinions and will post again when I have added further data to see if there is anything else.

    Autosave001.thumb.png.ca01b77f7387d8f3ae064d8002d916a5.png

    no_object2023-04-2573x30LEQModMount(CV)ZWOASI183MCPro_stacked.thumb.png.cb8134296696e8223a776facb1333e0d.png

    • Like 1
  10. On 19/10/2022 at 20:50, han59 said:

    In ASTAP you can convert colour files to mono, so single dimension. This menu can be found under main menu Tools (ctrl+M).

    You can also normalise raw OSC images. This routine makes the mean value of the R,G,G and B pixels equal. See tab "stack method" (ctrl+A) button "test normalize" This removes the typical raw checker pattern of raw OSC images.  It is intended to normalize flats but can also be applied on lights.   This normalize will keep the final image sharper then converting the debayered image to mono.

    Han.

    Hello Han.

    I have been trying to figure out how to do this procedure but for the life of me cannot get my head around it. I have read the guide ASTAP, Astrometric Stacking Program (hnsky.org) but there is no mention or walkthrough to guide you through the process. Do you have anything that shows it step by step?

    cheers

    steve

  11. 2 hours ago, vlaiv said:

    And do you know what ASI Air did when binning the data? Did it perform operation that I outlined above? If so - color can be preserved.

    Do have another look at my previous post - it explains two different ways of x2 binning that can be performed on OSC data. Both are bin x2 - and one is "naive" bin x2 - that is suited to mono data and destroys color information - while other is still bin x2 - but it is suited to OSC data and preserves color.

    If you have color data in the end - second version was performed.

    I am not aware there is more than one bin option in ASI AIr, I shall have a look later

  12. 1 hour ago, vlaiv said:

    Everything is right if done properly.

    Bin x2 simply means following:

    - reduce width and height of the image by x2

    - improve SNR by factor of x2

    - average 2x2 pixels to produce single output pixel

    (see there is everywhere number x2 present - similar thing happens with x3 bin and x4 bin and so on, except different number appears in each statement).

    In order to get black and white image - following must happen:

    image.png.0da2651e76c2d91c359f1ba64da42914.png

    You take group of 2x2 pixels of different "color" (different filter of bayer matrix) - and you average those to form output pixels.

    But if you do following:

    image.png.9200f7d99ac3fe3dfae4373a549b9632.png

    you take only red pixels (2x2 of them) and average them to red pixel, and you take 2x2 neighboring blue pixels and average those to one output blue pixel and you do the same with "top left" green group and "bottom right" green group - you preserve color information because you only average red with red, green with green and blue with blue pixels.

    Only when you average red, green and blue pixels together do you loose color information (in top example).

     

    What I did vlaiv was 2x bin in ASI Air whilst taking the subs, this is why I cannot understand as they should be B&W given that 2x bin can only be given you only have the one red, one blue and two green, or am I missing something very simple. 

  13. 2 hours ago, bottletopburly said:

     Have a look at @han59 reply in this reply regarding converting to mono in Astap may be of help 

     

    Thanks for that, I had already played around in that area but even trying playing around with the above, I cannot figure a way to create a B&W fits, still getting colour. Probably doing something very basic wrong!

  14. 2 hours ago, vlaiv said:

    Depends on how you bin them.

    Binning is trading spatial information for improvement in SNR. You basically "stack" adjacent pixels, so it is form of stackin but instead of temporal "direction", like stacking multiple exposures, you use spatial direction - you sum adjacent pixels.

    With OSC data you have two choices - you can pay attention which adjacent pixels you stack and preserve color, or you can just stack closest ones and then you destroy bayer matrix information and loose color.

    If you take 2x2 groups of pixels and produce single pixel in output - you loose color information.

    If you take 4x4 groups of pixels and produce 2x2 group of pixels in output with paying attention to only add relevant colored pixels together - you preserve information (and get the same result as if you used OSC camera with twice as large pixels but half of the pixel count in horizontal and vertical).

    Hmm this is what I did, 2x bin but still have a colour image. I have confirmed the binning in ASTAP but have a colour image. Seems something is not quite right.

  15. 11 hours ago, ONIKKINEN said:

    Convert to Mono in the tools? Not sure if this deals with your bayer matrix being visible but worth a try.

    Never actually looked at that interface and was looking at the file checking/stacking part of the interface, doh!

     

     

  16. 41 minutes ago, ONIKKINEN said:

    ASTAP is the king of platesolving, if you're using some other software to capture (like NINA) you can still let ASTAP handle the platesolving on its own. There is also a sky quality measurement tool in ASTAP where you can measure your sky brightness from the images you have taken and dont have to rely on some external measurement like lightpollution.map. You can also do image annotation with the most common deep sky objects in the M,NGC,IC,PGC,Common stars catalogues. There is a blink tool as well, something that is missing from other free stacking software (as far as im aware). I know the tool does stacking as well, but this i have not used myself so cant say how it performs.

    Handy tool, great price to performance ratio being free and all.

    Thanks for the reply, yes free is always a great price. I have to be honest the main thing that interests me is the bayer algorithm for OSC cameras. 

    I recently rekindled my interest in spectroscopy and only having a OSC is detrimental to results. Having a free programme to equalise the pixels into a mono, binned super pixel is cheaper and as effective as mono. Well at least this is what I am hoping for.

  17. Has anyone got any experience with using the ASTAP programme, I would like to know more about it 

    The home page for it is here ASTAP, Astrometric Stacking Program (hnsky.org) but having had a quick whizz through it, it appears to be something of a one page bible!

    Anyway, before I dive in head first I feel some background info and user experience would be a good idea if there is anyone who can help with this!

    cheers

    steve 

  18. I am using a 183mc for obtaining spectra for spectroscopy purposes. It really helps your results if you can use black and white. My camera isn't B&W so I can bin, however the FITS will still retain most of the bayer pattern in them. 

    Is there a way of removing bayer pattern from the raw FITS images to smooth out my results. 

     

  19. A timely thread this as my table is currently full of gear (mainly eyepiece) I am considering selling. I shall spend a little more time sitting and thinking about this before I list any of the items. That said, I have been mulling this over for about 4 months as it is!

    • Like 2
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.