DBE and ABE model

[jase]

Being away for a couple of months I've not had time for processing any images until now.  After launching PI and receiving several updates, the DBE and ABE model output appears rather coarse.  I don't recall it being like this in previous version (or perhaps I've simply forgotten!  ).

The distinct gradient lines are visible in the DBE output image hence I would like to know if there is a configuration parameter that can be changed to resolve this?

Thanks

[Cleon_Wells]

jase, in Model Parameters (1), increase the Tolerance value to around 1.0 and increase the samples per row to 15 in Sample Generation.
There is an art to these adjustments, so experiment, remember after you change a setting click in another adjustment box  to load the new setting.
Cleon

[jase]

Thanks for the quick reply Cleon.

I don't believe the issue is sampling based.  I have 20 good samples per row with nothing on bright stars or extended objects.  I hear you though, some experimentation is required.

What mystifies me is that DBE is actually doing the opposite of what it was designed to do as the model doesn't fit the image data - no matter which settings I tweak.  It is as though its operating in 4bit mode only capable of modelling 16 shades compared to a full 16bit or higher.  Due to this, it is actually producing background artefacts as the transition between different areas of luminosity isn't smooth.  The distinct lines shown in the model come through into the output data.

I've attached what I've explained to provide a better understanding.  Also I just reset PI back to defaults - same problem.

version
PixInsight Core 01.07.00.0702 Starbuck (x86_64)
PCL 01.00.96.0377
Copyright (C) 2003-2011 Pleiades Astrophoto

Thanks

[Cleon_Wells]

jase, I see your problem, I haven't had a problem with DBE on my images. I work with 32bit subs and use DBE on my 32bit linear integrated master.
Cleon

[georg.viehoever]

Is the image to which you apply DBE in float format? If it is integer, it may cause such issues.
Georg

[RBA]

Yes, some info about the original image could be helpful. Is that background model an auto-SFTed image? Are you applying it to a linear o non-linear image?

Increasing the number of samples is something that goes along with the particular needs of any given image. IMHO it shouldn't be suggested as a "general tip".

In fact, my "general tip", especially when dealing with gradients, would be trying to keep the number of samples low unless you know exactly why you'd need more (which you might, of course).

[jase]

Is the image to which you apply DBE in float format? If it is integer, it may cause such issues.
Georg

Thanks for your input Georg.

The image is indeed in integer format, not floating.  Though I'm not certain if that is the root cause.  Opening the 16-bit int file and saving it as 32-bit floating, then opening this and performing DBE again yields the same result.  I have just tried this with other images thinking that there is something wrong specifically with one image, alas it occurs on them all.

Why wouldn't integer format be supported with DBE?

I could swear that this functionality was working as expected prior to the last few major PI updates.

Yes, some info about the original image could be helpful. Is that background model an auto-SFTed image? Are you applying it to a linear o non-linear image?

Increasing the number of samples is something that goes along with the particular needs of any given image. IMHO it shouldn't be suggested as a "general tip".

In fact, my "general tip", especially when dealing with gradients, would be trying to keep the number of samples low unless you know exactly why you'd need more (which you might, of course).

Thanks Rogelio.  Sure.  The original image (or images as it now turns out) are basic 16bit int format.  Whether they are FITS or TIF is irrelevant as the same problem is experienced.  These are unstretched images so to speak.  There is a common element however in that they are being created in ccdstack, though as mentioned am near certain DBE worked fine in the past.  The presented background image is indeed autoSTF'd.

Thanks

[sleshin]

Jase,

Perhaps you're already doing this, but regards the appearance of the background model with stretching, apply the same autostretch with the STF to the background model as used on the linear image. With the trackview icon enabled on the STF, click on the autostretched linear image to set the values used on this image in the STF. Then, without clicking on the background model, transfer the STF values to the background model image by dragging the new instance icon to the backgd model image. That should give you a smoother backgd model  image.

Steve

[pfile]

but hang on though, there's posterization evident in his background-subtracted image. my first thought was that the background model was extremely smooth, hence the posterization when applying STF. i think that's what you are getting at, right steve?

[Ginge]

I see tips posterization regularly when applying auto stf to my images but have attributed it to the heavy stretching of an image with smooth gradients. I haven't seen any artifacts in the background-extracted images that corresponds to the lines in the posterized screen-stretched background image either.

Best regards,
Ginge

[Andres.Pozo]

The STF uses a less precise transformation than HTF. When applying very large stretches the STF shows posterization but since its is only for the visualization it does not matter. If you apply the same transformation using HTF the results are smooth.

If you drag the triangle of the STF panel to the botton of the HTF panel, the STF parameters are transferred to the HTF.

[jase]

Thanks guys.  I appreciate the input.  I'm missing the link here though.  STF should not impact the calculations of the background model established by the DBE tool.  They are independent right?

Pfile picked up the key point in that the background model itself is posterized, not just how its being displayed.  This is proven since the posterized model is be applied to the source image and creating the artefacts as seen in the previous post.

[georg.viehoever]

Hi Jase,

the reason why I suggested to use floats is that floats have a much larger dynamic range than integers. In particular, if the values created for the Background in DBE are very small (i.e. in the order of 1/(2**16) in float terms, or <1000 in integer terms), you get posterization with integers. Floats handle this smoothly because values are scaled by an exponent.

Your are right, STF does not influence the result. But apparently it is less accurate then a full Histogram Transform, presumably to be fast. I have also seen cases where STF cause posterization, but with HistogramTransform everything was fine.

Georg

[jase]

Thanks for the explanation Georg.  I understand the logic of floats having a larger dynamic range / bit space.  Based on this, would I be correct in making an assessment that the DBE tool does not always work within the bit space bounds of the source image?  If DBE is presented with only 16bit integer data, I would have expected it to be able to work with it.

[pfile]

Thanks guys.  I appreciate the input.  I'm missing the link here though.  STF should not impact the calculations of the background model established by the DBE tool.  They are independent right?

Pfile picked up the key point in that the background model itself is posterized, not just how its being displayed.  This is proven since the posterized model is be applied to the source image and creating the artefacts as seen in the previous post.

oh, but now i understand what steve was trying to say - STF is what's posterizing the data in the DBE result. the suggestion was to try applying the STF as a histogram transformation and see if the posterization goes away.