cgarry

I have updated PIPP's website with some notes about running PIPP on Linux using Wine and thought that it is worth mentioning here.

See https://sites.google.com/site/astropipp/downloads/installing-pipp-on-linux-with-wine for details.

I am still planning to produce a native version of PIPP for Linux and OS X, but hopefully this will help somebody in the meantime.

Cheers,
Chris

On 17/06/2016 at 07:47, uhb1966 said:

In my opinion, the biggest obstacle to overcome Windows is the lack of a good planetary stacker and a good deep sky stacker, but maybe someone  has a tip for that area of software?!

Posting again!

Stackistry 

Cheers,
Chris

4 minutes ago, Vox45 said:

ho the humanity !

INDI Forum Admin : "I think I would have to add a warning NOT to use Mint since it's pretty old compared to Ubuntu. It's recommended to download Kubuntu/Ubuntu 16.04 and then you won't have problems with the PPA"

In that case I would recommend Ubuntu MATE 16.04, not the standard version of Ubuntu with the Unity desktop.  I found the MATE desktop to be much more intuitive coming from a Windows background.

Nearly forgot, this from @GreatAttractor is quite new but looking good so far:

Stackistry (https://stargazerslounge.com/topic/269011-stackistry-a-lucky-imagingimage-stacking-tool/)

Chris

How about:

oaCapture (http://www.openastroproject.org/oacapture/)

SER Player (https://sites.google.com/site/astropipp/ser-player)

Siril (https://free-astro.org/index.php/Siril)

PIPP and AS!2 with Wine.

Nigel,

If you are doing this for planetary imaging and there is significant empty space around the planet then it is worth getting PIPP to crop the frames around the planet while it is doing the MOV to AVI conversion (https://sites.google.com/site/astropipp/example-uasge/example1B).

This will greatly reduce the memory and processor power that RegiStax will need.

Another thing I would advise is to use AutoStakkert!2 (http://www.autostakkert.com/) for stacking instead of RegiStax.

Cheers,

Chris

Thanks, Steve. I tried PIPP but still get an error message when attempting to open the AVI in Registax. But I'm going to investigate PIPP further since this is the first time I have heard of this program. So I guess I'll be using Autostakkert to stack and then Registax for its wavelets. Thanks for that suggestion, Zakalwe.

Your problem is almost certainly that Registax is only handling old format AVI files.  PIPP will generate these (Output Options Tab->AVI File Options->Generate Old Format AVI FIle) but they are limited to a maximum size of 4GB.  There are some ways to get around this in Registax, but I think using AS!2 for stacking and Registax for wavelets is the best solution.

Cheers,

Chris

I have a 120MC and a 120MM and they are both fantastic cameras.  Though you do have to work at it, great images don't just fall out of them!

Here is one of Mars that I took with the 120MC:

Note that there was a C14 telescope in front of the camera which does help an awful lot!

Cheers,

Chris

wait, isn't this the method everyone uses with the ccd cameras using icap, sharpcap etc?!? i'm confused

The are various capture programs that capture raw data from fast frame rate cameras (often incorrectly referred to as web cams).  Sharpcap, FIrecapture and oaCapture are these type of programs.

Then there are various programs the appear to do a similar thing for DSLR cameras (such as 'EOS Camera Movie Record'), these are the programs I am referring to.  In general it is simply not possible to get raw (or lossless compressed) video data from DSLR cameras.  These programs give the impression that you are getting raw data, but all they do is convert the lossy compressed data into a raw AVI.

Chris

Although these programs generate lossless AVIs, they do by converting lossy video (or a series of JPEGs) into a lossless AVI.  The damage has already been done to the data and I doubt there is any quality advantage to working this way.

I tried to record a video now at home in FINE, and it's bigger than the one i posted here...i guess it was only 30mb because except for jupiter all around were only black?

Ah yes, the size of the compressed data will depend on the subject in the video,  That could explain the strange file sizes.

From my reading on the internet, FINE is the setting you want.

The file sizes you recorded make no sense to me, or at least they seem to be the wrong way round.  Also 300MB for a 2 minute, 30 fps, 1920x1080 video is tiny!  There is no way that is lossless!

Cheers,

Chris

From http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC:

H.264 is typically used for lossy compression in the strict mathematical sense, although the amount of loss may sometimes be imperceptible. It is also possible to create truly lossless encodings using it — e.g., to have localized lossless-coded regions within lossy-coded pictures or to support rare use cases for which the entire encoding is lossless.

Yes, H.264 can be lossless, but I have never come across this in the real world.  You capture file is certainly not lossless, it is far too small for that to be the case.

I would choose 'AVCHD FINE' as it will be better quality, though I am pretty sure it will still be lossy.

Cheers,

Chris

That is great news.  Thanks for testing that version of PIPP, I will get it released in case it is causing others are having the same problem.

I don't use avchd files myself, but I know of a few guys who have used it.  Although the 'planetary imaging rules' say that using lossy video is a bad idea, I have seen some very nice results created from DSLRs using lossy videos.

I had a quick play with your video and I could not get any more detail out of it than you did.  As soon as I applied any kind of wavelets to the stacked image it just exploded with onion rings.  I am not sure why this happens but the low levels in the video (around 30%) almost certainly do not help.

Cheers,

Chris

Didn't work =( It's the latest pipp's release, i don't know why it doesn't accept mts!! =(

I have sent you a PM with a link to an updated version of PIPP that should handle .mts files again.  Could you try this version and let me know if it works for you?

Cheers,

Chris

I've seen that u import a dib file into pipp, which is the same codec of the output...i will try some converter that can do avchd into dib then

It looks like I have lost the .mts extension from PIPP's video type list at some point. Could you try changing the filename to end in .mov instead of .mts and see if PIPP is happy with it then?  That just tricks PIPP into accepting the file.

Cheers,

Chris

• Uhm ok...then I'm gonna have to still use avchd and convert it into avi without losing quality. Another thing: I've read that PIPP accept avchd but when I tried to import the file there it just says I can't...any suggestion?

PIPP should support avchd files, it certainly does for all the files I tested.  What is the error you are getting?

Thanks,

Chris

I did think that would be quick for another release...

I think you should go with your plan of getting the major functionality working before doing your next release.  Even if your release notes state exactly which controls do and do not work, I can guarantee that most users will not read them and then try and use the controls.  I think that the best approach is to disable any controls that are not implemented so it is obvious to the user. 

Keep up the good work!

Chris

I have set up one of my old laptops with Mint 15 in anticipation of your release!  Though it does seem to me that you have taken on a long term, full time project with this one...

Cheers,

Chris

a bit of documentation to write

That is an unusual step for open source software...

I thought I was getting about half the 8-bit frame rate in 16-bit mode with my ASI120MM in FC, so I was happy enough.  Though I only tried it briefly so I could be wrong.

The trouble with all these more obscure AVI features such as -ve heights it that other software, especially video players, often fail to support them. 

Chris

James,

I found the same thing when I investigated 16-bit mono video.  It mostly gets interpreted as RGB 565.  The Y16 codec is defined but I never followed it up as SER is a better format.

Also, a frame size of 640 x -480 is perfectly valid.  It just means a vertical flip is required.

I can't find any recognised pixel format definition for raw video frames, nor a codec that directly handles them.  Is anyone else aware of one, or shall I just shove them in an uncompressed raw video stream and assume the user will sort the details out later?

Mainly raw colour video just uses a mono video codec and it is up to the user/software to organise the debayering.  The exception to this is the BY8 codec which is the same as the Y800 codec (as implemented by TIS, ie not true Y800) but the decoding software knows it needs to be debayered.

Chris

A quick thought, if you are going to include support for the SER format you should get permission from Heiko Wilkens at http://www.astrofactum.de/Astrofactum/LucamRecorder/.

Cheers,

Chris

The 120MC definitely supports raw output.  For greyscale video I just set R, G and B to the same value in the Ut Video codec and that does a good job of compressing the file to less that 50% of its original size (depending on the video).  I played around with a lot of other lossless compression codecs but found nothing available that was any better than the Ut Video codec.

For 16-bit greyscale video I have seen the Y16 codec but do not know of anybody that has used it, I know of no 16-bit video with compression though.

My thoughts are that we need a better system than the flakey AVI format which causes no end of grief.  What we need is something like the SER format, but one that also supports colour data and compression.  We need some brave individual or team to write a specification and provide open source code for creating and reading the format!  I thought briefly of taking this on myself but quickly realised that I do not have any spare time.

Cheers,

Chris

I know what you mean, it can be hard to convince yourself to sit down at a computer in the evenings and weekends when that is what you do for your day job.  With PIPP I tend to work in bursts, completing blocks of functionality and then have breaks in between where I only work on bug fixes.  Working in this way keeps my enthusiasm for the development going and the project stays alive.

Yes, you definitely should get monochrome support working, including raw un-debayered video from colour cameras that support it.  Obviously to maximise the framerate across the USB cable as well as the final file size.

Chris