881 replies to this topic

[LauraMS]

Hi Rolf,

Re flat frame I very well know the situation without flats - sometimes I forget them, or for one reason or the other they are not useful :-)

I completely understand that dust is not easy to get ignored - maybe it can be detected by means of the fact that it does not move at all while - at least at the resolution I use - most 'real' details move or are at least 'warped'. And dust usually is significantly larger than one pixel, but not very large. Just some ideas which come to my mind but maybe you have better ideas. Or just implement flats ;-)

If you need solar data as a use case just let me know.

Best wishes,
Laura

Edited by LauraMS, 21 May 2019 - 05:12 AM.

[Rolf]

Hi Laura,

 

Thank you very much for sharing your ideas! I don't think it would be easy to detect dust by how it looks like. That would take way too much computing time (e.g. using machine learning techniques). Your other thought is much better, and very close to what I already had in mind. I measure shifts in two places: At the global scale during image stabilization, and then later when I measure the local warp at each AP. The nice thing is that I use two different mechanisms for the two phases. Since, as you wrote, the dust does not move on the sensor, at an AP which is dominated by a large dust speck, the warp shift exactly counteracts the global frame shift. And this is the same for all frames. It is VERY unlikely that such a coincidence is caused by seeing. Therefore, I only have to look for this pattern at all APs and elimnate those where this is the case. Should work very well, and (very important) not cause much computing overhead.

 

I will try this out soon. The next three days, however, I will be on business travel. So PSS has to wait for a while.

 

All the best,

 Rolf

 

PS: Thank you for offering solar test data. That will be very useful during the gradual improvement of the code. As soon as I have a new version, I will announce it in this forum.

[Rolf]

This is an update on the recent PSS developments. There is good news and bad news.

 

Let me begin with the good news: Meanwhile I implemented and tested the dark / flat frame calibration. I added a menu "Calibration" where you will find all the necessary functions.

 

 

I also improved the RAM management. At the beginning of each job PSS checks if there is sufficient RAM available. If that is not the case, there is an error message, and PSS continues with the next job. If the protocol level is set to the highest value, PSS even recommends a different buffering level for which the RAM should be sufficient. Using the first prototype several users reported problems with program crashes when they tried PSS on long video files. I suspect that most of those crashes were due to an incompatibility of the selected buffering level and the available RAM.

 

I encapsulated all video import functions in the single class "VideoReader". My friend Michal Powalko has taken responsibility for its serious implementation. When that is done, PSS should work with all kinds of AVI and SER files, color and monochrome. At that point I will produce the next release of the software. So far, you can access the current version as source code on the "development branch" on Github only. There you will find also the updated User Guide.

 

So much for the good news. And now the bad one: While PSS so far successfully passed all tests on the moon and the sun, it recently failed on a Jupiter video. Cyril Richard (developer of SIRIL) had tested PSS on a Jupiter video produced by Jean-Luc Dauvergne. The video was strongly affected by seeing, but AutoStakkert!3 nevertheless produced a quite acceptable result:

 

 

PSS, with comparable parametrization produced this image:

 

 

Obviously, the AS!3 result is clearly superior. I would have assumed that stacking a Jupiter video is a similar task as stacking a lunar mare with little structure. This does not seem to be true. (By the way: Don't worry about the artifact in the PSS image of the neighboring moon. I could have avoided that by setting a proper alignment point on the moon manually.)

 

This setback on planetary videos was a sad experience. I have no idea yet as to the reason for the bad PSS performance, and I almost felt like stopping work on PSS alltogether. Worst of all, I do not have any idea what is the reason for the diverging results on the sun/moon as compared to Jupiter. I hope to find a way out of this bad situation sometime.

 

All the best,

 Rolf

[wargrafix]

Please do not give up. This reminds me of the registax vs autostakkert move.


If I had to guess, it might have something to do with alignment box size. Depending on the size of the boxes your results can vary wildly.

[Rolf]

Hi,

 

Thanks for your encouraging words. But after months of algorithmic work and the success on the moon and the sun, this Jupiter result was just too frustrating!

 

I wish the problem could be solved with changing the AP box size. I tried a wide range of sizes, without any success. Somehow the local warp shift measurement does not work . I mean, if you look at those low-contrast patches which are blurred additionally by bad seeing, it seems like a miracle is needed to measure anything reasonable. I tried different metrics and Gaussian filter widths, but nothing helped.

 

Vincent Hourdin, one of the SIRIL authors, is currently implementing my algorithms in SIRIL, so he is facing the same problem. I'm discussing possible solutions with him. That is nice, because this way I'm not completely on my own.

 

All the best,

 Rolf

[wargrafix]

one thnig you software handles superbly is the Jupiter moon. I love it. I have not followed the thread closely, forgive me. Is there an installer for the software?

[Rolf]

Sorry, but the Jupiter moon is not handled well in my experiment above. The dark spot in the middle is an artifact caused by improper alignment. I could have avoided that if I had set a suitable alignment point manually. So, this is just a "user mistake" and nothing to worry about.

 

You can download the Windows installer from Gibhub. This is still the first release without the additions I mentioned in yesterday's posting.

 

All the best,

 Rolf

[wargrafix]

Ohhhhh. Don't beat yourself up too much. Time and study might provide insight to help you solve your issue.

[wargrafix]

Also, if its superb with moon and sun but not hot with Jupiter (as yet) then let's use it as a moon and sun tool. Registax still is king for wavelets

[Euphonia]

Agreed, a solid tool for the moon alone is worth gold.

[Rolf]

Hello,

 

Thank you very much for your nice words! As to the performance on Jupiter, I have not yet lost the hope to find a solution. At the moment I'm brainstorming with my friends Cyril Richard and Vincent Hourdin of the SIRIL project. All this will take some time, though.

 

In the meantime I have implemented full support for dark and flat frames. I added a "Calibrate" menu:

 

 

The semantics are very similar to what you know from AutoStakkert. It seems to work just fine. I updated the user guide in the Github repository to reflect the changes.

 

My friend Michal Powalko started work on the VideoReader class. The aim is to include support for AVI and SER videos, both monochrome and color, with different bit depths. Also, large files should be supported. Michal is the first person except me who actively contributes to this open source project. I'm very happy about that!

 

All the best,

 Rolf

[Rolf]

Hello,

 

Since I'm very busy with preparing talks on the 50th anniversary of the first lunar landings, I didn't make any progress yet in finding the "Jupiter problem". But at least there is some news on the postprocessing capabilities of PSS.

 

So far you could define several sharpening layers to bring out detail hidden in the summation image. By doing so, however, one introduces high-frequency noise. Therefore, it is a good idea to apply a low-pass filter with a somewhat smaller radius after sharpening. I now included this option in PSS. The following example illustrates that:

 

 

(You have to click on the image to start the animation.) The blink comparator shows two postprocessing versions (2 and 4), the latter one being the current version the parameters of which are shown above. Sharpening is set to a radius of 6.1 and amount 21.12. After that, there are two low-pass layers with radius eqal to 3.2 and 2.0, respectively. Here you see that the amount is negative (between 0 and -1). This tells PSS not to sharpen, but to apply a Gaussian low-pass filter. At a setting of 0 nothing happens. At -1 the full filter is applied. This way the low-pass filtering is seamlessly integrated into the postprocessing layer concept.

 

The postprocessing version 2 which is compared with the current one in the blink comparator does the sharpening only, without low-pass filtering afterwards. As you see, the resulting image is much more grainy, without showing more detail.

 

This feature will definitely become part of the next software release. In August I will have a few weeks of vacation. I plan to work on the "Jupiter problem" then.

 

All the best,

 Rolf

Edited by Rolf, 07 July 2019 - 03:10 AM.

[wargrafix]

I am downloading 050, Can I drop a raw stack in to apply sharpening?

[Rolf]

Yes, you can. Just read the user's guide. On page 4 you find how you define a job (in this case a postprocessing job), and on page 13 you see the details how you can set the sharpening parameters.

[wargrafix]

Dude.....dude....dudeeeeeeeeee

 

 

I ran my stack data through your program, and you are being to hard on yourself. Its friggin excellent.

 

I mean if you are finding ways to improve it, then I am rolling with you to the end of the line, but dude, the software is awesome.

[wargrafix]

Registax

 

Planetary system stacker

 

Implement color channel align, and the reign of registax will come to an end. Just saying.

 

The software is excellent

[APshooter]

Does this program employ wavelets for sharpening?

[wargrafix]

I think it does

[Rolf]

Hi there,

 

Thank you so much for your nice words! It is good to read that my software works well on your data. However, I still have to find the reason why there are cases (like the Jupiter video I showed above) where stacking with AutoStakkert!3 works better. And I'm determinded to solve this problem.

 

As to the sharpening algorithm, I experimented with wavelet sharpening but finally created an algorithm which could be described as "multi-level unsharp masking". Algorithmically this is very similar to wavelets, but it's much faster. In my tests I didn't find any example where wavelets in AviStack2 (so far my favorite program) gave better results than my code. The only thing missing so far was the option to ad a low-pass filter layer to reduce high-frequency noise. That's why I added this option last weekend.

 

Color channel alignment is very simple and very hard to do at the same time! The solutions available so far (like in Registax or Giotto) just shift the image globally by a fixed amount as to remove color fringes as well as possible. That's trivial to implement, and for planetary images it's good enough. Since my main target is the moon, however, this is not an option for me. For large moon panoramas, the optimal shifts between the color channels vary across the image, so a constant shift does not help. I wrote a software called "PlanetarySystemLRGBAligner" which is very much more sophisticated. It should be possible to perform the global color alignment using the 2nd processing phase of that software (based on a "dense optical flow" algorithm). I plan to experiment with that, and perhaps some time later I will add this functionality to PSS. But that's not my highest priority for now.

 

All the best,

 Rolf

[Kokatha man]

<"However, I still have to find the reason why there are cases (like the Jupiter video I showed above) where stacking with AutoStakkert!3 works better. And I'm determinded to solve this problem.">

 

Great to hear this Rolf!

 

<"The solutions available so far (like in Registax or Giotto) just shift the image globally by a fixed amount as to remove color fringes as well as possible. That's trivial to implement, and for planetary images it's good enough. Since my main target is the moon, however, this is not an option for me. For large moon panoramas, the optimal shifts between the color channels vary across the image, so a constant shift does not help.">

 

Going to your link for PlanetarySystemLRGBAligner jogged my memory somewhat - it is true that Registax enables a simple channel shift of r&b relative to the green but this isn't always adequate, even for planetary images...optimal shifts do vary across the image quite often & you end up using "workarounds" to get both the limb & more central aspects aligned... 

 

I should look into PSLRGBAligner a bit more...in the meantime I know you have a lot of interested people following your work!

 

 

[wargrafix]

I have yet to RTFM, but will try a little later.

Will you be implementing SER use?


What is required to implement drag and drop. Like dropping an image to utilize the sharpening function.

By the way, I tried the program on my saturn and moon stacks. All I will say is win/win.

[Rolf]

<"However, I still have to find the reason why there are cases (like the Jupiter video I showed above) where stacking with AutoStakkert!3 works better. And I'm determinded to solve this problem.">

 

Great to hear this Rolf!

 

<"The solutions available so far (like in Registax or Giotto) just shift the image globally by a fixed amount as to remove color fringes as well as possible. That's trivial to implement, and for planetary images it's good enough. Since my main target is the moon, however, this is not an option for me. For large moon panoramas, the optimal shifts between the color channels vary across the image, so a constant shift does not help.">

 

Going to your link for PlanetarySystemLRGBAligner jogged my memory somewhat - it is true that Registax enables a simple channel shift of r&b relative to the green but this isn't always adequate, even for planetary images...optimal shifts do vary across the image quite often & you end up using "workarounds" to get both the limb & more central aspects aligned... 

 

I should look into PSLRGBAligner a bit more...in the meantime I know you have a lot of interested people following your work!

I could have guessed that there are those planetary photography experts like you who are not satisfied with the constant channel shift even in the planetary case. 

So it seems that a more sophisticated channel alignment could be useful beyond the moon.

Just one caveat: The purpose of the PSLRGBAligner is not color channel alignment, but to align a B/W panorama with an RGB one. It warps all three RGB channels in the same way in an attempt to match them with the B/W image. That said, the following experiment could be worth trying:

•     Extract the green channel of an RGB image and store it as a monochrome 16bit Tiff. Let's call it "image 1".
•     Then extract the red channel and convert it to a 16bit RGB Tiff ("image 2", all three channels being equal).
•     Do the same with the blue channel ("image 3").
•     Now run the PSLRGBAligner, taking "image 1" as the B/W image, and "image 2" as the color image. Select the option "Skip first phase" in the configuration. Store the warped color image, and "flatten" it to monochrome. This will be the new red channel.
•     Do the same with "image 3" instead of "image 2". This will be the new blue channel.
•     Combine the green channel with the new red and blue channels into an RGB image.

At every pixel location the program tries to align the three images (color channels), computing a local warping as required. This should work as long as the three color channels are not too different (i.e. as long as colors are not very pronounced). A good candidate, therefore, is the moon, where colors only become visible later by increasing the color saturation. Jupiter with its vivid colors could be a problem, though. I plan to do this experiment sometime soon with a large moon panorama. If it works, this procedure could be easily included in PSS postprocessing.

All the best,

Rolf

[Rolf]

It's always a good idea to RTFM! 

 

And it's amazing that you seem to have used the program successfully without reading the manual.

 

I have yet to RTFM, but will try a little later.

Will you be implementing SER use?


What is required to implement drag and drop. Like dropping an image to utilize the sharpening function.

By the way, I tried the program on my saturn and moon stacks. All I will say is win/win.

A friend from Danmark, Michal Powalko, is currently working on the video import. He told me that 8bit monochrome SER is already done, and at the moment he is working on the de-bayering for color mode. Eventually, the plan is that PSS will support both AVI and SER (8 and 16bit). Probably we will not support MOV. Not because it would be hard to do, but because its compression artifacts would lead to unpredictable results later on in stacking. As soon as Michal has finished a first stable version of his code, there will be a new PSS release.

 

I really don't know if I want to implement the drag and drop functionality. It would not be hard to do, but I do not want to overload the user interface. Do you think it would be too cumbersome to use the file chooser for selecting the input file?

 

I'm glad to hear that the program worked both on the moon and saturn!

 

All the best,

 Rolf

[wargrafix]

To be honest drag and drop is a huge part of the speed aspect for me. Having to start the import process all over again is ok for a few times, but with 50 files, that not going to be fun for anyone. Right now I can see this program working in my workflow pretty well.

 

Also, the wavelet speed is butter fast. Well done!

 

Sometimes the solutions to problems can come out of the air in the middle of the evening. Sometimes your solution may come out in version 2. Look at sharpcap. It took several versions before it got dark subtraction right.

[wargrafix]

 

Here is another data stack i processed with PSS