Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_dslr_mirrorlesss_winners.thumb.jpg.9deb4a8db27e7485a7bb99d98667c94e.jpg

Recommended Posts

Hello I posted this in Discussions - Software which I think may have been the wrong place to put it so I have also posted in this fourm

I have been capturing some avis of Jupiter last night using my DFK and I just tried a quick process in AutoStakkert but when I opened them most of the avis it looks like this below. The only thing I can see that is different is on the odd one where this doesn't happen the bayer is gbrg whereas on the ones where this strange effect is happening it says either mono or grbg. I captured them all in y800/y800. I don't know what has happened.

Has anyone seen this before?

Sam

post-9821-0-67583100-1358348462.jpg

Share this post


Link to post
Share on other sites

Do they look the same if you just play the AVI on media player or something similar or if you put them into Regi or PIPP?

Share this post


Link to post
Share on other sites

I get that in Registax 6 too. Don't have an answer-only a workaround. I use PIPP to preprocess the videos before I use Registax or AS. I think I would use PIPP even if I didn't have this problem now.

Mark

Share this post


Link to post
Share on other sites

You could try running the avi through PIPP to see if that helps.

James

Share this post


Link to post
Share on other sites

I get that in Registax 6 too. Don't have an answer-only a workaround. I use PIPP to preprocess the videos before I use Registax or AS. I think I would use PIPP even if I didn't have this problem now.

Mark

Thanks I'll try that. Whats confusing me is why has it happened!! I did about 15 avis and I think only 3 or so do not do this in AS!2. I've been using my DFK for nearly a year now and it has never happened before.

Share this post


Link to post
Share on other sites

Well I tried PIPP and it corrected the strange oblique shape on the preview screen however I think whatever happened messed up the bayer pattern as I can't debayer the output from PIPP in AS!2 so the best I can is a monochrome image.

Its very bizarre but what is irking me is that I don't know why the output from this session turned out like this. I'm just glad the conditions weren't great that night.

By the way I ran the avi from my best Jupiter image to date through PIPP before I stacked in AS!2 to compare the outcome and it wasn't as good. By some way. So I'm currently not convinced of the need to run through PIPP prior to AS!2.

Sam

Share this post


Link to post
Share on other sites

Well I tried PIPP and it corrected the strange oblique shape on the preview screen however I think whatever happened messed up the bayer pattern as I can't debayer the output from PIPP in AS!2 so the best I can is a monochrome image.

Hi Sam,

If PIPP is doing any kind of centring or cropping of raw colour data but it is not actually doing the debayering itself, you need to select:

Processing Options->Bayer Pattern Protection->Protect Bayer Pattern When Centring/Cropping = Enabled

Otherwise, the bayer pattern in each frame is shifted about by an unknown amount and pretty much nothing will be able to recover the colour data.

As an aside, I am not sure how well PIPP's quality algorithms work with raw colour data is PIPP is not debayering the data, I suspect the bayer pattern will register as local contrast changes and mask the genuine contrast changes it is trying to calculate.

Chris

Share this post


Link to post
Share on other sites

Hi Chris,

Thanks for the response.

I was thinking the original error or event that might have happened that has caused the problem to show up in AS!2 might have somehow also affected the bayer pattern?

In PIPP I did not ask it debayer the data and I did select the Protect the Bayer Pattern option.

Sam

Share this post


Link to post
Share on other sites

I have seen effects similar to your original error before, but that was down to video decoders that did not understand the line padding that is required with the DIB codec (if the number of bytes in each line is not a multiple of 4). However you are using Y800 which does not use this padding. Was your video 640x480 or did you use a smaller region?

Actually if PIPP was not cropping or centring the video, then the protect bayer pattern option is obviously not needed. It might be worth seeing if PIPP can debayer the video, that would at least show if the colour data is actually in the video.

I have used IC capture with Y800/Y800 before but forgot to turn off the debayering in IC capture which I have on for focusing. The effectively throws away the colour data, very annoying if it is a good quality capture! That is quite obvious though if you look at an enlarged frame as the bayer pattern should be obvious.

Chris

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.