Some ideas for new functionality

addon: the above called "artificial" luminance files are rather called "synthetic" luminance files.

Posted by: schurig

Hi,

The proposals in this posting relate to new functionality:

Statistical information:

When I draw a box in the main image window I would like to know statistical information for that image area: max./min ADU value, standard deviation, S/N ratio, median, average, position and size for the selected box. I noticed that some statistical information is saved in the Fits header but I want to do this on the fly. The statistical information should be available for the whole image as well.

I think it would be best if I make a dynamic tool for this which you can use always when an image is displayed in the image viewer, right?

By clicking on a small button above the image viewer, the tool could be started, allowing you to draw a rectangle in the image and then the results would be shown in a pop-up window or on the left/right side of the image viewer, will need to give that some thought.

I know this is an interesting feature to implement and can help in diagnosing issues with data (like calibration) or simple check data characteristics.

Fits-Header:

My imaging software (SG Pro) puts a lot of good information in the header (SITENAME, FILTER, OBSERVER, etc.). When I stack files with APP this information is currently not preserved in the resulting file. Why? In case of the FILTER information this would help such a lot and could be used practically:

• display a warning when trying to stack flat frames that have different filter information
• identifying the channel of a master flat correctly (even after years)
• naming files including the filter abbrevation (e.g: G-St-avg-960.0s-WSC_1_3.0-x_1.0_LZ3-NS-full-qua-add-sc_BWMV_nor-AA-RL-MBB5-1, instead of only St-avg-960.0s-WSC_1_3.0-x_1.0_LZ3-NS-full-qua-add-sc_BWMV_nor-AA-RL-MBB5-1 … leading to less overwrite conflicts
• in the RGB combine dialog the channel could automatically be preloaded via this header information

I would generally suggest preserving as much Fits Header information of the source files as possible!!!

I agree but only to the extent where it follows FITS conventions, other keywords in the fits metadata would be application specific and to manage that would be really cumbersome probably. I use SGP myself by the way 😉

If the keywords aren't following fits conventions, then that should be addressed to the developers of that application off course.

If you can give me an overview of which FITS header tags would be useful , according to you, to exploit, I'll be happy to add this to my priority list 😉

Artificial luminance files:

Ok, this is kind of a special proposal, but it would be quite unique and for taht reason a USP. No other software (as friends told me not even PI can do this comfortably) has it implemented. In my workflow I create artificial luminance files from my single R, G, B frames. So R1+G1+B1 … Rn+Gn+Bn becomes Lart1 … Lartn. These artifical luminace frames Lart1 … Lartn are then stacked with the real luminance frames. This method is best for minimizing noise. But achiving the art. luminance frames ist hard work. Every single RGB frameset has to be calibrated and registered (but not normalized). You then stack the three frames by adding the values. An 'add' stack method is not available. But a good work around for that in APP is the RGB combine tool. Loading every frame, redirecting every frame to the luminance channel and setting the factor to 3x. Then save this combined image as the artifical luminance frame. When having 10 RGB-Sets then do it 10 times. In PI you can write a script, but it would be cool having such a function in APP in the normal UI.

Ok, enough for today.

Thanks,
Stephan

-

Okay, I actually do this myself in APP. I create luminance from combining Luminance + red + green + blue filter data. The resulting luminance has higher quality than the integration of only the luminance files.

Why do you mention, they shouldn't be normalised?

What you can do to achieve this.

1) First register all data in one single go

2) Then load the registered data per channel, in 4) use the "no registration" mode. And proceed with normalizing the data of that channel. Then save this registered + normalised data per channel. 

3) Then load all registered + normalised data and simply integrate with average mode without normalisation in 5). That will be the same as adding the data like your suggestion. In my testing and experience, it actually can be useful to also normalise the data between the channels, but that's probably a separate discussion.

So I think, your proposal is already perfectly possible with APP unless I miss some specific detail on how you want to create the artificial luminance ?

Kind regards,

Mabula

Posted by: Mabula Haverkamp

Hi Stephan,

Thank you very much for these proposals.

Let me respond:

Posted by: schurig

Hi,

The proposals in this posting relate to new functionality:

Statistical information:

When I draw a box in the main image window I would like to know statistical information for that image area: max./min ADU value, standard deviation, S/N ratio, median, average, position and size for the selected box. I noticed that some statistical information is saved in the Fits header but I want to do this on the fly. The statistical information should be available for the whole image as well.

I think it would be best if I make a dynamic tool for this which you can use always when an image is displayed in the image viewer, right?

By clicking on a small button above the image viewer, the tool could be started, allowing you to draw a rectangle in the image and then the results would be shown in a pop-up window or on the left/right side of the image viewer, will need to give that some thought.

I know this is an interesting feature to implement and can help in diagnosing issues with data (like calibration) or simple check data characteristics.

Such a tool would be great. Thanks. Another point came to my mind: Show the current ADU value for cursor position and 3x3 mean (without having to draw a box)

Fits-Header:

My imaging software (SG Pro) puts a lot of good information in the header (SITENAME, FILTER, OBSERVER, etc.). When I stack files with APP this information is currently not preserved in the resulting file. Why? In case of the FILTER information this would help such a lot and could be used practically:

• display a warning when trying to stack flat frames that have different filter information
• identifying the channel of a master flat correctly (even after years)
• naming files including the filter abbrevation (e.g: G-St-avg-960.0s-WSC_1_3.0-x_1.0_LZ3-NS-full-qua-add-sc_BWMV_nor-AA-RL-MBB5-1, instead of only St-avg-960.0s-WSC_1_3.0-x_1.0_LZ3-NS-full-qua-add-sc_BWMV_nor-AA-RL-MBB5-1 … leading to less overwrite conflicts
• in the RGB combine dialog the channel could automatically be preloaded via this header information

I would generally suggest preserving as much Fits Header information of the source files as possible!!!

I agree but only to the extent where it follows FITS conventions, other keywords in the fits metadata would be application specific and to manage that would be really cumbersome probably. I use SGP myself by the way 😉

If the keywords aren't following fits conventions, then that should be addressed to the developers of that application off course.

If you can give me an overview of which FITS header tags would be useful , according to you, to exploit, I'll be happy to add this to my priority list 😉

I think, actually only the filter information is urgent with the above mentioned implications of using this information practically.

Any other information may be quite not reasonable: Lights from different observers with different telescopes are combined - so the e.g. OBSERVER header is not unique. So we can discard that header information.

Artificial luminance files:

Ok, this is kind of a special proposal, but it would be quite unique and for taht reason a USP. No other software (as friends told me not even PI can do this comfortably) has it implemented. In my workflow I create artificial luminance files from my single R, G, B frames. So R1+G1+B1 … Rn+Gn+Bn becomes Lart1 … Lartn. These artifical luminace frames Lart1 … Lartn are then stacked with the real luminance frames. This method is best for minimizing noise. But achiving the art. luminance frames ist hard work. Every single RGB frameset has to be calibrated and registered (but not normalized). You then stack the three frames by adding the values. An 'add' stack method is not available. But a good work around for that in APP is the RGB combine tool. Loading every frame, redirecting every frame to the luminance channel and setting the factor to 3x. Then save this combined image as the artifical luminance frame. When having 10 RGB-Sets then do it 10 times. In PI you can write a script, but it would be cool having such a function in APP in the normal UI.

Ok, enough for today.

Thanks,
Stephan

-

Okay, I actually do this myself in APP. I create luminance from combining Luminance + red + green + blue filter data. The resulting luminance has higher quality than the integration of only the luminance files.

Why do you mention, they shouldn't be normalised?

What you can do to achieve this.

1) First register all data in one single go

2) Then load the registered data per channel, in 4) use the "no registration" mode. And proceed with normalizing the data of that channel. Then save this registered + normalised data per channel. 

3) Then load all registered + normalised data and simply integrate with average mode without normalisation in 5). That will be the same as adding the data like your suggestion. In my testing and experience, it actually can be useful to also normalise the data between the channels, but that's probably a separate discussion.

So I think, your proposal is already perfectly possible with APP unless I miss some specific detail on how you want to create the artificial luminance ?

I meant, the channels musn't be normalized between each other (because the information for the specific color would be falsified, wouldn't it?). I agree that all images of the same channel can be normalized, but actually it is not necessary (because in my workflow the normalization takes place when the added RGB frames are combined later with L frames)

There are two things I do not understand (maybe my mathematical knowlege is not good enough, so please excuse if I talk nonsense :-))

1) The average: In theory a luminance frame should be about third times the values of the summed up RGB values. So simply spoken: If I have a R-frame with values of about 4, B frame with values of 6 and a G-frame with values of 10, then a luminace frame should be around 20. If I average my RGB values I get a frame with a value of 6.6, averaging this frame with a real L frame would lead to a frame with 13.3. But I'm really not sure if the absolute values is decisive from mathematical point of view?

2) Let's say we have 5 frames RGB each. What you do is create one master luminance frame from 15 frames. What if I have real luminance frames e.g. 10? Do I add them to the list, so that I eventually combine 25 frames to one master luminance frame? The question for me is:

Is Sigma-Combine-Average(R1, R2, ... ,Rn, B1, B2, ... ,Bn, G1, G2, ... ,Gn, L1, L2, ... +Lm) the same as

1. Add(R1+B1+G1) = X1, Add(R2+B2+G2) = X2 ... Add(Rn+Bn+Gn) = Xn
2. Normalize(L1, L2, ... , Lm, X1, X2, ... Xn)
3. Sigma-Combine-Average(L1, L2, ... , Lm, X1, X2, ... Xn), optionally with LNC

or when it is not the same, does it lead to significantly different results?

Kind regards,
Stephan

Kind regards,

Mabula