5.49
#...
·
 |
|---|
|
Hi Jeffrey, Still keen to see what happens when you stack your lights with no flats  Have you posted this question to the PI/WBPP forum ? Cheers, Gary |
3.61
#...
·
|
|---|
|
Hi Gary, It's on the agenda for this weekend to do some troubleshooting. I will keep everyone posted of my findings. CS, Jeff |
|
3.61
#...
·
|
|---|
So I spent a good amount of time on the red frames only this weekend and basically the only way I could get a "functional" image was if I only calibrated with either bias or darks. Any time I added flats things would go haywire. Unless I didn't calibrate the flats and just used the raw integrated flat with the raw integrated light data then I would get an image that was essentially a negative of the flat with the light data barely visible in the background. My flats were taken a bit early at dusk and the exposures are very short. Here is a dark processed light integration: I just don't get why the blue frames worked okay (VERY similar flat durations, etc.) but red and green go haywire. Now to add to the weirdness of this set of data, I also did luminance images and those refuse to process at all if flats are involved with the following log of the WBPP: ProcessLogger.txt |
|
3.61
#...
·
|
|---|
| Well at least progress on the luminance front. I found a bad flat file (essentially a blank file) that caused things to go crazy. Of course now I am left with a luminance that exhibits the same issue as the red and green where there is a very bright section at the bottom of the integrated image. |
5.76
#...
·
|
|---|
| Any chance you could provide an actual flat and actual stack of flats for red? |
|
3.61
#...
·
|
|---|
| Linwood, do you want the actual fits? A single red flat fits and a calibrated stacked fits (5 individual frames)? |
|
5.76
#...
·
|
|---|
|
I'm really curious so yes. At least a single red flat fits, preferably the calibrated stack as well, and if you like a single red light? (I'm assuming that calibration with the dark is not having much impact, since you have narrowed this down to the dark). I am not sure I will find anything more than you have, but my guide camera failed on the first good imaging night in months and I'm bored.  |
|
5.76
#...
·
·
1
like
|
|---|
|
I'm now still puzzled but for other reasons. I just loaded these and ran WBPP with pretty much nothing unusual, and I got the opposite of what you had, the bottom of the master frame is dark. That's the one on the right below. For reasons unclear I decided this may be related to local normalization, though I cannot say why, so I reran it with everything the same except turned off local normalization.  And it's gone, it looks correct and good. And I have no idea why. The LN master looks fine, it is clean and has no gradient.  The calibrated lights and registered lights have no gradient. The only thing I can think of is that the white band at the bottom is causing some issue during the local normalization, but that seems to make no sense since there is a white band on the left. I also have no explanation why you got completely different results than I did. For clarity, the WBPP process I ran calibrated the flats with flat darks, lights with darks and flats. Nothing unusual. if I can figure out a simple way to do it, I'm going to crop off the bottom and right and rerun the whole thing again. But at this point I'm more confused than i was before, since we got different results. Mine was V2.5.9 with PI 1.8.9-1 build 1556 (so I am pretty far behind, I did not install the new versions due to all the troubles). |
|
3.61
#...
·
|
|---|
| Well that's interesting. I am at the latest version of PI. The WBPP I ran was at full default values. |
|
5.76
#...
·
|
|---|
| I'm going to try the crop first, but I had planned to upgrade, I can see if that makes a difference. I probably have some differences from defaults, but they are few, large scale rejection is on for example. Let me try a few variations. |
|
5.76
#...
·
|
|---|
|
Removing (cropping) the band at the bottom fixes it so that local normalization does not create the gradient. My GUESS is that's some kind of smoothing that LN is doing to try to deal with the bad. Why it doesn't do it on the left I do not know (too small? The bottom is worse). I do need to upgrade. I think I'll do that anyway and since I have it all set up, try again. |
|
3.61
#...
·
|
|---|
I thought I tried running it without LN but maybe not....trying to keep tract of all the iterations I was trying was getting out of hand. I needed to take a more methodical approach and was going to do that the next round. Of course I was also getting caught up in why my luminance wouldn't process at all. This one has been a head scratcher for me in pretty much all areas.  |
|
5.76
#...
·
|
|---|
I upgraded and have the latest of everything, I reran it WITH local normalization, without the crop (i.e. as I did the first time), and got similar but better results. It appears local normalization is reacting differently. Latest on left, May 2023 version on right. So I have no clue why your gradient is the opposite of mine. If you are curious to compare, here are the settings I used. parameters.txt The Monkey Head line is ignored since the reference is auto. If you compare to your script it may give a clue, or post yours and I shall, as you like. I think it's wrong what it is doing with the band at the bottom, though I suspect the PI folks will say "you shouldn't have a band at the bottom". By the way... why is there a band at the bottom and left? |
|
3.61
#...
·
|
|---|
| Suspect the bands are related to camera driver overscan settings in TheSkyX that I have selected? And how do you get the parameters.txt file? Probably not going to be able to get to any more troubleshooting until later this week. I did see there is an overscan setting in WBPP but don't know how to make changes to it. |
|
5.76
#...
·
|
|---|
| Take the WBPP screen before you run it, and drag the triangle on the bottom left to the PI desktop, then right click on it and edit source. |
|
3.61
#...
·
|
|---|
|
Got it: WBPP.txt |
|
5.76
#...
·
|
|---|
|
I am unable to see anything that matters. I woke up thinking it might be large scale integration rejection, but turning that off did not have impact. I was disappointed to find I could not just run your file, maybe there is a way to do so but could not find it. I assume the 5 images, at least lights, are a sample. Maybe the white you got, versus dark I got, is related to the number of images stacked. If you run your script only on these 4 x 5 images, do you get the white band not black? But I think the underlying issue relates to those bands, and it sounds like that might be some TSX anomaly. If that's coming from TSX and not necessary, I would certainly suggest fixing it. I think arguably PI's LN should not be impacted by it, but I guess data is data, and if it's doing some kind of smoothing as part of LN maybe it makes sense. And I don't feel bad blaming TSX for something after all the troubles I had with it back in the day.  |
|
3.61
#...
·
|
|---|
|
LOL, yes...I remember your trials and tribulations (was with a MyT correct?). Going forward I will revisit the overscan setting in the camera driver but that doesn't really explain this issue not showing up before and also not showing up on the blue frames... It is also odd that the overscan area is showing up black in the flats but white in the lights. |
|
5.76
#...
·
|
|---|
Jeffery Richards: I suspect it is because that area of the sensor is shaded and so not sensitive to incoming light, but is sensitive to noise and exposure time (etc). So if you look at a flat (which is mid-histogram) the edge remains similar to the dark of the same time. This means when it is subtracted, that area goes essentially to zero, a black area on the flat. The light had a longer exposure and so more noise, when its dark is subtracted you get a a dark value but probably not full zero (or worse it goes negative, not sure if it truncates or loses the sign). So you are dividing by something close to or equal to zero, making the result large (white). At least that's my theory, I am a bit troubled why the light is not also near zero after the dark subtract and so it is zero divided by zero. But I assume the noise level somehow is responsible. I also tried pedestals but couldn't get it to actually use one (where "it" is the image calibrate process not wbpp). |
|
3.61
#...
·
|
|---|
| Certainly sounds reasonable...but still doesn't explain the blue working fine. When I get a chance this week (hopefully before the weekend), I'm going to start all over from raw data and make sure my WBPP is fully reset to defaults and process again (maybe with LN disabled for the first crack). |
|
5.76
#...
·
|
|---|
|
Yeah, the other thing I don't get is how for me it went to black and yours went to a white gradient. But it may be a side effect of the larger stack. At any rate, I think I see where the mystery comes from even if I can't follow the entire convoluted path, so I'm happy and will go take a nap and wait for my new camera to come.. |
|
3.61
#...
·
|
|---|
|
Yeah, the full stack is 80 frames. Might rerun with just the five I posted to see if things are different. I appreciate the help Linwood. So what's Santa bringing? |
|
5.76
#...
·
|
|---|
|
A replacement ASI174MM that failed on the first clear night in months. This hobby is quite hard on avoiding issues. It's like the old potato chip commercial, but with problems -- "solve all you want, we'll make more". Post what you find, still curious. |
|
3.61
#...
·
|
|---|
| Yeah, it's always something. Around here it's just getting clear skies more than anything else. Will be glad when I fully retire and can image any day of the week without worry (and possibly move to a more astro-friendly location if I can convince the better half). |
