Blinking Script

[Nocturnal]

It all depends on what your purpose is. For image grading it is more useful to have whole image statistics. To analyze an individual image it is useful to have access to individual star metrics. DSS already stores metrics for all stars it detects in the <image>.txt file so it's a simple matter of writing a program that processes that data. No one's been motivated enough to do that yet

With individual star metrics you could do something ala CCD Inspector.

[NKV]

New button "Series Analysis", like AIP4WIN whole images analysis.

[Nocturnal]

Very nice! That's something else I wrote as a standalone tool a long time ago

[Niall Saunders]

Looks great Nikolay,

I am eager to try it out 'for real' when I get back to my main PI machine.

Cheers,

[Niall Saunders]

Nikolay,

I was just reading through your script, and I came across the following :-

Code: [Select]

   //---------------------------------------------------------------------------------------
   // Generat Statistics
   this.StatGen = function()
   {

      if (Boolean(this.stat[this.curentImage])) return; // generate Statistics only 1 time
      var sс = new Array();
      for ( var c = 0; c < dest.mainView.image.numberOfChannels ; c++ )
      {
         dest.mainView.image.selectedChannel = c;
         sс[c] = new ImageStatistics (dest.mainView.image);
      }
      this.stat[this.curentImage]=sс;
   }

I am not sure what you originally used when you typed in the variable declaration for sс but something doesn't seem right. I am sure it 'works', but it doesn't 'read' easily. (Yes, I know this is just a 'triviality', but I thought I would mention it anyway)

Cheers,

[NKV]

I am not sure what you originally used when you typed in the variable declaration for sс but something doesn't seem right. I am sure it 'works', but it doesn't 'read' easily. (Yes, I know this is just a 'triviality', but I thought I would mention it anyway)

Hi, Niall. My mistyping. I write c in Russian keyboard layout, so I see it like sc.
Anyway, I updated the attachment. Thank you, and tell me if you see any other disadvantages.

[Niall Saunders]

I like being able to expand the window 'vertically' (to be able to see more of the list entries), but it would also be nice to expand 'horizontally' to see more of the filenames (mine tend to be rather long, and the numeric ID tends to be at the far right!!)

Yes, I will modify.

I also wondered about being able to use the mousewheel to 'scroll' through the listed images. At the moment, the mousewheel affects the zoom. I don't know which function is more suited to wheel actions, zoom or image-select?

Niall, just move mouse cursor to FileList and use mousewheel  

Nikolai,

I don't know if I am missing something, but I still can't get the view window to flick through the images by any other means than 'slideshow' or by clicking the 'left' and 'right' arrow icons.

As far as I can see, using the <UP> and <DN> keyboard cursor keys will select the previous or next image 'in the file list' - but they do NOT change the displayed image on the screen.

Similarly, the scroll-wheel 'scrolls' the file list up and down, without changing the highlighted file, and without changing the displayed image on the workspace.

I was looking for a quick way to 'toggle' between two images on the list, and the cursor keys seemed to be the 'natural' method, in conjunction with a duplicated method using the scrollwheel

Obviously, if the little thumbnail is 'clicked', then the scrollwheel does a perfectly good job of 'zooming' - no problem there. Maybe if the lower panel of the GUI is clicked, the scroll-wheel could then be changed to allow step-by-step movemment through the image list?

==========

Also, I thought I had hit some sort of 'fatal bug' when I clicked the "AutoHistogramTo All Images" button - I hadn't spotted the console window running through ALL of the 60 images that I had loaded. Perhaps some sort of interim "Recalculating ..." MsgBox is needed - to let the user understand that there may be some delay?

==========

I really LOVE the "Series Analysis" tool. I compared the data with that from AIP4WIN and the results were 'spot-on' (within the limits of floating-point rounding errors, anyway!). I would have preferred to see the data in [0.0, 65535.0] range and wondered whether that sort of option might be possible.

At first I thought "This would be better if it directly 'mimicked' the AIP4WIN output", but then I quickly realised that PixInsight will suddenly be able to provide a far more detailed series analysis, so there would be no advantage in 'sticking to the AIP4WIN' format - so no problems there (although I did think of a 'customisable' GUI that allowed users to select FITS header values for inclusion in the series analysis - perhaps even a GUI that allowed users to choose which of the 'soon to be many' analysis parameters that they actually needed).

In the long-term, this script will benefit from being able to 'save' and 'restore' user-customised settings - most likely it needs to behave like a 'core process', capable of dropping a PJSR 'icon' on the Workspace for later re-use, or storage.

==========

I would also have preferred a file selection window that appeared once the PJSR was running - not right at the opening stage.

It would also be great if files could be cleared, toggled, added, deleted on the list - as is common with other multi-image selectors (more like ImageIntegration and StarAlignment, but NOT like the ImageContainer interface, which I feel is too 'non-standard')

==========

In fact - for Juan here - have we now reached the stage where "multiple file/image selection" is, in itself, a 'process' that needs to be defined,  and therefore given a common GUI across ALL processes that require it?

==========

If you remember, in my original series of thoughts (on the other thread that you have already referred to, I also had tried to describe how there could be a concept of a 'BlinkMaster' image - an image that was used to blink-compare the remainder of the entire series of images, or an image that could be compared 'back-and-forth' between any other single selected image.

Can anyone think of a 'tidy way' that this notion could be implemented? Perhaps, if enabled, the 'slidehsow' would be 'turned off' and the delay timer would simply be used to toggle between the BlinkMaster and the currently selected image. As soon as a 'cursor key' (or the scroll-wheel) is ised, the BlinkMaster is then 'toggled' back-and forth between it and the 'next' (or 'previous') image in the selected file list?

==========

Could there be a possibility of 'importing' the STF from 'outside' the PJSR? In other words, you pick one of the images, set up a non-auto STF to get the image looking the way you need it to look, and then use THAT set of STF parameters for all images appearing in the Blink routine?

I can see how it would work if this was a 'core' process. You would drag-and-drop the 'apply instance' icon to the bottom of the GUI, just as we already do with the STF and Histo (where I exchange settings ALL the time now - thanks for THAT little enhancement, Juan).

Question is - can this be done inside a PJSR?

==========

Remember I mentioned the possibility of throwing a simple Dark subtraction and Flat division at the images? This would be a nice direction for this script to develop. Again, just let the user know that it will take a few seconds for the selected images to be 'calibrated'.

And, for those wishing to blink 'Bayered' images, then a simplistic deBayer process might also be a future way forward as well

==========

And now, when the user has finally selected a 'good' subset of the original data, perhaps an option could be given to actually 'do something' with those images which remain IN the selection (and for those images that were eventually EXCLUDED from the selection).

Perhaps the option to designate the remaining selection as 'good darks', from which a MasterDark could now be made (and the same would apply to all other calibration frame sub-types)

==========

Maybe this is where the script starts to 'grow arms and legs' - where separate 'tabs' start to appear. One for each sub-frame 'type'. Suddenly your excellent front-end 'blinker' becomes what ImageCalibration is crying out for.

A method of classifying ALL raw images in one go
A method of sifting through all of those raw images to ensure that only the most 'robust' data makes it into the final melting pot
A method of quickly changing a few parameters, and the re-running the ENTIRE calibration and alignment routine with one mouse-click, where ONLY those stages that NEED to be re-run actually get re-executed
A method of then being able to save the ENTIRE calibration phase as ONE (albeit complex) process icon

==========

In any case Nikolai, even with what your routine already provides, you have done excellent work - and I am sure that Juan would be delighted to include your script with the 'standard distribution', even in its current format. I would actually like to see someone take the time to help you code this as a PCL routine. It really deserves to become a mianstream 'core' module in my opinion.

Thanks for all your hard work.

Cheers,

[Harry page]

Hi

Love the improved auto stf to every image if selected , I can see how bad all my images are 

I have a problem that if I select statistics I cannot close the processing console down without closing down the script

Now if you could just sort out the calibration , I might just buy you a beer  8)

Many thanks for your work , I will use it a lot 


Harry

[NKV]

Niall, thank you for attention.

using the <UP> and <DN> keyboard cursor keys will select the previous or next image 'in the file list'

Done. Now you can use <UP> and <DN> to navigate thou ALL files. and you can use <Left> and <Right> to navigate throw only Checked files. So you can select 1 image as BlinkMaster and blink it with other one.  

Similarly, the scroll-wheel 'scrolls' the file list up and down, without changing the highlighted file, and without changing the displayed image on the workspace.

Done. scroll-wheel = <Left> and <Right> = Previous / Next buttons.

to let the user understand that there may be some delay?

Now better? MesageBox will later.

I would have preferred to see the data in [0.0, 65535.0] range

Now you can edit the script:

Code: [Select]

var r=65536;   // multiplier, write 1.0 if you like to see data in [0.0, 1,0]
var n=3;       // digits after dot.
I will populate the control with other settings and controls in next version.

Could there be a possibility of 'importing' the STF from 'outside' the PJSR? In other words, you pick one of the images, set up a non-auto STF to get the image looking the way you need it to look, and then use THAT set of STF parameters for all images appearing in the Blink routine?

If the script will take STF from active window during start? OK?

And now, when the user has finally selected a 'good' subset of the original data, perhaps an option could be given to actually 'do something' with those images which remain IN the selection (and for those images that were eventually EXCLUDED from the selection).

I see too much way to 'do something' with 'good' subset... IMHO power of PI in flexibility, implement all instruments in one tools it's utopia, so I think 'do something' much ease via HDD (copy or move or rename). But, if you want, I will try to send 'good' subset to other PI instruments (to Integrate/Calibrate/StarAligment/ImageContainer ).

I have a problem that if I select statistics I cannot close the processing console down without closing down the script

Harry, to close console just push Play button.

Best regards,
Nikolay.

[RobF2]

Wow.  Thanks again Nikolay.  Can't believe how useful and how quickly this tool has come along! 

[Harry page]

Hi

Thanks again , and for the tip on the play button 

I tell you what if you could do simple calibration in a tool like this ( I have a sx camera and do not require fancy dark thingys ) I would buy you 2 beers  8)


Harry

[NKV]

I would buy you 2 beers  8)

I like beer, but right road to the beer goes through PCL. I think PCL is much faster. I am right?

[Carlos Milovic]

Yes, PCL modules work faster than scripts (in most cases, very few exceptions work quite at the same speed).

[Harry page]

Hi

Crikey you drive a hard bargain , 3 beers then, and I don,t care if its slow 


Harry

[Carlos Milovic]

Talking about slow things... this reminds me when I was at a image processing course, working with MatLab. Then, I only had a Pentium 133MHz. So, I wrote a code, and tried to run it there. Acording to my estimations (from the status progress I wrote), the whole process (not a big thing) would take 2 days! So, I had to buy a 400MHz laptop, and there it only took from 2 to 3 hours
At this point, I gived up with matlab, and continued solving the homeworks with the PCL (btw, this was some 5-6 years ago).