Closed davidenitti closed 3 years ago
Hi David, what capturing software and what file format do you use. Interestingly with a SER file it works, so why not stick to that?
I used sharpcap with a zwo asi178mc, and I tested different formats, RAW8, RGB and RAW16 (SER). I could use SER, but I was trying to understand the problem. I find it weird that with a standard RGB video I get such a blue color.
Thanks for the update. SER is just the file format you save your video in so you can technically save a RAW8, a debayered RGB or a RAW16 data stream into a SER file, which would save it uncompressed. Do you know what formats sharpcap uses to save the RAW8 and RGB videos?
RAW8 and RGB is saved as avi
Right. My first guess would be that it is a debayer issue. What happens when you use a RAW8? Also blue, like the RGB?
yes same thing, with RAW8 with bayer pattern has the same result of the RGB. it's weird because the RGB video is already debayered
oh maybe I found the issue, I have to select the job with right click to force RGB, I guess when I change the configuration is not immediately taken for the jobs
Hmm. That sounds like a mixed up debayer configuration. Can you confirm that it now works with RGB?
yes, but I have to make sure with right click that the RGB is selected (if the video is RGB) for the job
Right. Guess the auto-detection is then not working properly. Could you post a very short video here, so that we could try on our side?
Hi,
First of all, your observation is correct: If you have defined a job, changes to the global parameter "debayer pattern" do not change the debayer option for that job any more. You can delete the job from the list and select the file again, or you change the pattern for the existing job via the job context menu (right click).
The other question is why the automatic bayer detection did not work properly. You did not show us the protocol (using the highest protocol level 2), so we can only guess what happened. Most likely the PSS detection algorithm decided that it is BGR instead of RGB. The reason would be that the red channel is noisier than the blue one in your video, which would be very unusual. PSS uses the noiseness of the red and blue channels to tell them apart. In most cases the blue channel contains more noise. For cases as yours I added the option to force PSS to use a different pattern.
If you set the protocol level to 2, PSS reports which Bayer option it has adopted.
All the best, Rolf
I uploaded an example: I used the video https://drive.google.com/file/d/1MqW2JTYLRv-rnGdQgCRXAtSnDeKhrm2G/view?usp=sharing I get this result https://drive.google.com/file/d/1gY_8W2hZr8pE99_lcfR8jUQDZgvbv13E/view?usp=sharing I get this log (leaving automatic selection)
*****************************************************************************************************************
22-41-32.0 Start processing /media/davide/Seagate/Photos/planet_moon/moon_telescope/2021-02-26/Moon/output000.avi
Software version used: PlanetarySystemStacker 0.8.30
*****************************************************************************************************************
Stacking parameters: | Value |
---------------------------------------------------------------------------------------------
Debayering default | Auto detect color |
Debayering method | Bilinear |
Noise level (add Gaussian blur) | 7 |
Frame stabilization mode | Surface |
Automatic frame stabilization | True |
Stabilization patch size (% of frame size) | 33 |
Stabilization search width (pixels) | 34 |
Percentage of best frames for reference frame computation | 5 |
Object is changing fast (e.g. Jupiter, Sun) | True |
Alignment box width (pixels) | 48 |
Max. alignment search width (pixels) | 14 |
Minimum structure | 0.04 |
Minimum brightness | 10 |
Percentage of best frames to be stacked | 10 |
Normalize frame brightness | True |
Normalization black cut-off | 15 |
22-41-33.4 +++ Buffering level is 4 +++
RAM required (Gbytes): 6.79, available: 27.86
22-41-33.4 +++ Start reading frames +++
Number of frames: 151, image shape: (2080, 3096, 3)
Debayer pattern detected automatically: 'RGB'
Dynamic range of input frames: 8 bit.
No matching master dark / flat frames found, calibration de-activated
22-41-33.4 +++ Start ranking frames +++
Index of best frame: 133
22-41-58.0 +++ Initializing frame alignment +++
Alignment rectangle, computed automatically: 1356<y<2013, 1532<x<2524
22-41-58.1 +++ Start aligning all frames +++
Pixel range common to all frames: 9<y<2078, 7<x<3094
Maximal pixel shift between consecutive frames, vertical: 4, horizontal: 5
22-42-03.3 +++ Start computing the reference frame +++
The reference frame was computed using the best 8 frames within a window of 16 frames.
Quality loss of reference frame due to time restriction: 1.1%
Position of reference frame in video time line: 91.9%
22-42-58.7 +++ Start creating alignment points +++
Hi Davide,
I downloaded the video and processed it with PSS 0.8.31. When I process it with PSS 0.8.31 I get the following protocol: output000_stacking-log_p100_b48.txt
The file obviously does not match the protocol in your previous post. There are only 7 frames, and the image size is (1040, 1040, 3).
The protocol, however, shows that my assumption was right: The bayer pattern automatically detected is BGR, not RGB. If I force PSS to RGB, the color comes out right.
Therefore, I regard the issue as being resolved.
All the best, Rolf
I did a test with a video of a light bulb: but when I stack the video I get a blue light: I tested with RGB and RAW8 videos and I get the same results, also trying different debayer patterns. the only way it works is using ser video format.
how can I fix this?