DBE Sample Generation at Edges

[mcintyre_sj]

Is there a way to tell DBE auto sample generation to stay away from the edges?

For some reason, the fts file i stacked with DSS from CR2 files from a  Canon XS/1000d has black pixels around the edges - about 2 pixels or so all the way 'round. Its as it the image data from 4 pixels smaller than the file size.

So i now manually move all the pixels at the edges over a couple of pixels so they are sampling real background.

[Harry page]

Hi

As far as I know No 

There are two ways to look at this

1) The black pixels probably will not be used by DBE ( check sample box ) and why bother moving them 

2) I always crop my image to start with to remove misaligned frames and such things then I do not get the problem

Harry

[dhalliday]

Dynamic crop...
My favorite tool..!

Dave

[mcintyre_sj]

Thank Harry. I decided to go with the crop.

If my object of interest is only a small portion of the frame, is it better then to crop before any real processing? I generally have cropped at the last stage.

[georg.viehoever]

Hi,

cropping saves processing time and memory. So it is a good idea to do an inital crop first. In case of nebula and galaxies, I usually also keep plenty of background since this helps with DBE. I do the final crop later.

Georg

[Niall Saunders]

the fts file i stacked with DSS from CR2 files from a  Canon XS/1000d has black pixels around the edges - about 2 pixels or so all the way 'round

Are you using DSS to 'deBayer' the 'raw' CR2 files? If so, then this may be a (necessary) artefact introduced when the deBayer algorithm tries to porcess 'nearest neighbour' information from edge and corner pixels - where 'nearest neighbour' information isn't available.

In any case, even with 'perfect' guiding, you are still likely to end up with 'funny edges' on your final image - and it really does make life much easier if you apply an Auto STF right at the start of your PI workflow, and then use DynamicCrop to trim off the nasty edges (and, remember, DynamicCrop can also be used to 'rotate' the 'trimming lines' so you can also get your image 'back on the level' if image registration has introduced any form of rotation.

Definitely worth doing at the start of proceedings - and can sometimes be used at the end of play as well, if you are looking to 're-frame' your final image.

Cheers,

[mcintyre_sj]

Thanks all.

The note about leaving some background for DBE to work with was what i was really wondering about, but didn't explain my question very well.

I am using DSS ADH to debayer, automatic alignment to stack and "standard mode" as the results. I expect it's the nearest neighbor that causes the edge to dark. It's exactly 1 pixel all the way 'round.

[Niall Saunders]

Whenever a deBayer algorithm is written, the programmer must decide how to handle 'the edges' - simply because there is not the same amount of 'surrounding data' as found in a mid-image pixel.

In the deBayer routine that I wrote to learn all about PJSR, I effectively 'synthesise' the missing data, so that I don't end up with the 'empty' surround - but it doesn't mean that the data I end up with is, statistically, any better than just not processing it in the first place.

But, like I said, just don't worry about that outer edge of pixels - it is highly likely that you will want to crop much more than that off the edge of your stacked image in any case.

Cheers,

[Juan Conejero]

Hi,

As others have pointed out, you should crop registration or deBayer border artifacts systematically, as a first processing step. The DynamicCrop tool is an interactive tool that allows you to crop, rotate and scale images in a single operation.

On the other hand, DBE will (if properly used) reject too dark and too bright border artifacts automatically, even if you (or DBE's automatic sample generation) place samples over them. The rejected pixels will not contribute to background modeling; they will be simply ignored.

[Niall Saunders]

Hi all,

Remember - if you take the time to inspect the actual samples that you have set (manually, or automagically) on the image that you wish DBE to process, then you can consider each sample as a 'mask' in its own right.

If you correctly adjust the various other parameters (although you very often do NOT need to do this) then you should see that the littlle 'sample' screen should be 'black' where data is to be excluded from the DBE analysis process. In this way, a sample laid over a star should show that star as 'black' in the sampler preview area - in other words, the 'star data' will NOT be included in the DBE algorithm.

I would imagine (but cannot prove this from where I am working at the moment) that the same should be observed when samples are at the image edges, and where the image edges have deBayering artifacts - the artifacts should end up being 'totally black' in the sample previewer.

Can someone verify this?

Cheers,