PIPP - planetary imaging pre-processor software

[tonyowen]

[edit]

A good command line for you would be something like:

pipp -q=1000 -qhisto -ctr -c=150 -ms=10 "dubc+d.avi"

[/edit]

Chris

I've rerun the test01 and test08 with -qhisto.

Results and *.txt files are attached. What does the -c=150 option - may be I should look at the manual!!!

I'm now getting a bit confused as to what is the optimal set for each planet - assuming there might be one.

regards

Tony

dubc+d_pipp_log.txt

saturn03_pipp_log.txt

[cgarry]

Hi Tony,

The -c=150 option will crop the image to 150 x 150 pixels. This reduces the memory and processing requirements for the stacking software.

A few notes on the other options:

-qw

Quality weighting (experimental). Do not use! This option has been seen to offer subtle improvements with very good image data, it will not help with your very small images.

-qmin=2

-qmax=3

-qinc=1

Do not use any of these with -qhisto.

These options only apply to the standard quality algorithm or the old quality algorithm. They have no effect when the -qhisto option is used.

-rgb

This splits the RGB channels and is generally not used unless a very specialised/advanced processing routine is used. In your case it allows you to process just the blue channel as it has good brightness levels, ignoring the red and green channels that are overexposed.

I think we are now getting about as much out of this data as is possible. Now I think that you need some fresh captures where the R, G and B channels are more even and none are over exposed, then you should be able to capture a bit more detail.

Cheers,

Chris

[tonyowen]

I think we are now getting about as much out of this data as is possible. Now I think that you need some fresh captures where the R, G and B channels are more even and none are over exposed, then you should be able to capture a bit more detail.Cheers,Chris

I've had the white balance on auto with SharpCap - I'll investigate making it manual and examining the results of different R, B, G settings

Good weather etc etc willing I agree

regards

Tony

[cgarry]

I have not used SharpCap in a long time. Does it display a histogram for the video it is capturing? I have no idea how you can get the colours correct without that feature.

Good weather, yes I think I remember what that is. I am sure we had some before this drought started.

Cheers,

Chris

[WakeyTiger]

Hi Chris, consider me another 'guinea pig' if you need one! I'm using SharpCap to capture AVIs on my dob, so the planet moves across the eyepiece.

I tried PIPP on my most recent (best) AVI of saturn, but as I used the MJPG2 codec, it didn't work. So, I then tried PIPP on a previous capture I did - which was overexposed, but used the YUY2 codec.

PIPP functioned perfectly, using the below options:

>pipp -chk -ctr -avi <filename.avi>

This gave me a brilliant AVI of about 200 images, which were very static indeed. I now can't wait for a clear night, so I can try again with Saturn using the RGB24 option, as you specified is best.

My most recent image of Saturn is here - but as I said, Registax only managed to 'claim' a few frames, due to the planets movement across the f.o.v. - but I think I have the SharpCap settings right now...

Great work sir!

Matt.

[cgarry]

I am pleased to announce that PIPP v2.0 is now available on PIPP's website:

http://sites.google....site/astropipp/

This update is a huge change for PIPP and it is now a full windows application rather than a command line program. I hope that makes it easier and more intuitive to use.

PIPP is not nearly where I want it to be in terms of improvements and new features, but I wanted to get a working graphical version released sooner rather than later.

There is no manual available yet, but hopefully the examples on the website will fill in in the meantime.

Cheers,

Chris

[themos]

Many thanks!

[tonyowen]

Chris,

Just used the new version it runs very smoothly and very fast.

One observation, I had to exit the program before I could run an second avi - any inputted avi is not removed from the start page.

There did not seem to be a 'new' source file - only an "add source file".

regards and congratulations

Tony

[cgarry]

Chris,

Just used the new version it runs very smoothly and very fast.

One observation, I had to exit the program before I could run an second avi - any inputted avi is not removed from the start page.

There did not seem to be a 'new' source file - only an "add source file".

regards and congratulations

Tony

Thanks Tony,

I guess you were using the 'File Menu -> Add Source Files' route rather than the buttons on the window below the source file list. Since there is an option to add files under the File menu I think there really should be one to remove them too!

You can remove a file from the list by clicking on the 'Remove All Files' button below the list. You can also remove a file from the list be clicking on its entry in the list to select it and then pressing the Delete key on you keyboard.

Also, If you are going to process multiple files with the same options you can add them all to the list and process them all in one process run (Batch Mode).

Cheers,

Chris

[Freddie]

Thanks Chris. The command line version was great so looking forward to having a go with this version.

[tonyowen]

Chris

I have an avi file, converted from a mp4 video file taken with a hand held camera.

I tried to use pipp to generate a *.ser file.

(albeit I sucessfully used pipp to generate an avi file)

However, your program would not do this as it considered that avi to be in colour!!.

I could not find and option to process that avi as black & white.

(In Registax 5 a window opens asking if the avi is to be processed as co,our of B&W)

I did not change any of the defaults.

I wanted the *.ser file because AS!2 rejected the avi file generated by pipp.

What did I do wrong or what should I have done?

regards

Tony

[cgarry]

Hi Tony,

The development version of PIPP does have an option to convert colour to monochrome as a first processing stage, mainly added for solar imaging. This will be released once I have finished adding support for opening Canon RAW files which is a week or so away I guess.

For now though I would recommend using the 'Enable RGB channel splitting' option which would split the colour video into 3 monochrome channels and allow ser files to be written. You could then just use one of the three ser files generated for stacking.

Out of interest, did AS!2 give a reason for rejecting the avi file? I have not seen it reject an avi file from PIPP before.

Cheers,

Chris

[tonyowen]

Out of interest, did AS!2 give a reason for rejecting the avi file? I have not seen it reject an avi file from PIPP before.

Cheers,Chris

Thanks for response.

re AS!2 I'll try to repeat what I did and get a screen dump to you.

regards

Tony

[tonyowen]

re AS!2 I'll try to repeat what I did and get a screen dump to you.regards Tony

Chis

I started again from the mp4 file but couldn't repeat what seemed to happen before.

I start with the mp4 file, use format factory to get an avi file. The used VirtualDub to get an old format avi.

Finally used pipp to get (yet another) avi file.

I guess that earlier I tried to 'processed the wrong avi stage

regards

Tony

[cgarry]

Thanks fir the update Tony. I like your process flow, though you could do with a few more conversion stages!

Cheers,

Chris

[1CM69]

Hi Chris,

I have been using PIPP for a while now but not really in any great depth. 

Recently I captured some footage of Jupiter in .ser format & running it through PIPP with quality sorting enabled & outputting once again in .ser format, I noticed that the initial 174 frames of my capture from this output were completely blown out. 

I then noticed the 'Reject Over Exposed' option in PIPP & checked it. (left at default value 20)

I ran the process again but blown out frames were still there. 

Change rejection value to 10, same result. 

Lower the rejection value to 1, again, still 174 blown out frames at start of Outputted .ser. 

Am I doing something wrong?

I would have thought that the blown out frames should have been quality sorted to the end of the .ser file, shouldn't they?

 

any help would be appreciated. 

 

Regards..,

Kirk

[cgarry]

Can you please look at the file in SER Player and use the histogram viewer to see if the blown out frames actually any have pixel values of 255?  Also if you could save a few (2 or 3) of the blown frames in another SER file (SER Player can do this) I would be interested in examining them and with a view to fixing PIPP.

Cheers,
Chris

[1CM69]

1 hour ago, cgarry said:

Can you please look at the file in SER Player and use the histogram viewer to see if the blown out frames actually any have pixel values of 255?  Also if you could save a few (2 or 3) of the blown frames in another SER file (SER Player can do this) I would be interested in examining them and with a view to fixing PIPP.

Cheers,
Chris

Thanks for replying Chris.

I had a look at the histogram & the Red channel holds steady at 250 but both the Green & Blue channels max out at 255 for all 174 frames.

I have created a .ser file containing these blown out frames, here's the link; https://www.dropbox.com/s/yt9fwl9j5pntt79/22_06_22_pipp_F00001-00174.ser?dl=0

 

Regards..,

 

Kirk

[cgarry]

Ah, I have just checked the source code and the problem is it was checking for the sample value being equal to 65535 in 8-bit mode. before deciding it was overexposed  This was never going to work well with values that max out at 255!  This algorithm is somewhat simplistic and does not handle the case where values max out below 255, but that is a problem for another day.

I will do a quick fix for now and it would be good to see if it works with your data.

Cheers,
Chris

[1CM69]

32 minutes ago, cgarry said:

Ah, I have just checked the source code and the problem is it was checking for the sample value being equal to 65535 in 8-bit mode. before deciding it was overexposed  This was never going to work well with values that max out at 255!  This algorithm is somewhat simplistic and does not handle the case where values max out below 255, but that is a problem for another day.

I will do a quick fix for now and it would be good to see if it works with your data.

Cheers,
Chris

Thanks for looking Chris.

So, is PIPP actually working as designed & my data is no good for it to analyse, or is it a bug?

The reason I had over exposed frames was because I was messing with Gain & Exposure during capture in a failed attempt to fight poor seeing.

 

Cheers

Kirk

[cgarry]

Hi Kirk,

No, this is very much a bug!

Cheers,
Chris

[1CM69]

1 minute ago, cgarry said:

Hi Kirk,

No, this is very much a bug!

Cheers,
Chris

OK Chris. ?