DBE and ABE model

[Harry page]

Hi

I have only seen this on jpeg images that I was trying DBE on ,

Is there any way you could let us see the image in question , or you can upload it to my FTP server if you desire to of course 

Harry

[jase]

Following suggestions here;
Performing an STF to HistogramTransformation does smooth out the model but as others have highlighted, this is ultimately a visual guide.  In both cases the DBE output continues to have posterization.  I'm not proficient enough to push PI for on this as it may well be something I'm doing differently.  My requirement is to operate DBE on unstretched/linear integer data.  This has worked in the past.

More than happy to share the data as this was only a 'fill in' data set I shot while waiting for the main imaging run targets to rise (the fill in is nothing special!). It is of the PGC galaxies surrounding NGC1365.  It is a 96Mb 16bit tiff (integer - no compression) zipped to around 30Mb.  This is the combine RGB data.  Have not got to the luminance as yet.

http://cosmicphotos.com/reprocessed/NGC1365surrounds.zip
File will only be available for a short period of time.

I would certainly like to know if you experience similar challenges with the data.  If not, what did you do to address it?
From my perspective, this is easily reproduced.
Open the tiff in PI
autoSTF it so you can see whats going on
Launch DBE and place samples as needed
apply
autoSTF the model - eekkk looks scary
autoSTF the DBE output - ekkk even scarier...

[jase]

I should also highlight that if I take the approach;

Open tiff in PI
Launch DBE and place samples as needed (rather difficult to visually see whats going on as no STF applied)
Apply DBE
Save the DBEoutput as a tiff
Open in Photoshop, start stretching with curves etc...

Posterization still exists in the DBE output image!!!  Confirms STF has nothing to do with it.

[pfile]

it's not that the STF is causing it, it's that the STF histogram transform may end up posterizing certain data. but of course since it's just a screen stretch, it's not actually changing anything.

later tonight i'll try that image and see what happens.

just a hint, while working on the STF'd image, you can drag the DBE triangle to the desktop, thereby creating a process icon. you can drag this icon to another image of the same dimensions and it will execute the DBE. no need to redo the samples on an unstretched/un-STF'd image.

[jase]

...but of course since it's just a screen stretch, it's not actually changing anything.

Agreed. Thats the logic I'm working with.  Though the DBEoutput image defies this!  I seriously hope its just something I'm doing wrong but am beginning to doubt it is.  In review of previously created astro images, I can confirm I've successfully been able to achieve the task before.

[pfile]

i don't really know why this is happening. the values in the extracted background are very, very small (0.0014 to 0.0016) and so perhaps subtracting such small numbers and converting back to i16 yields posterization.

at any rate, if i explicitly change the sample format to f32, everything works as expected.

after you load the tiff image, open the SampleFormatConversion process and convert the sample format to f32. doing the DBE on the f32 version gives the expected result - no posterization. the STF on the background model is still posterized but as steve suggested if you actually apply the STF autohistogram to the HistogramTransformation tool and apply that to the background image, you will see that it is smooth.

i think you tried to do this by saving as a f32 file and reopening it, but somehow this does not work, i guess.

[jase]

Converting from i16 to f32 format, then performing DBE didn't work for me, Pfile.  I get the same result. I double checked that the file converted correctly, which it did given the fits header now listed 32bit. To ensure it had nothing to do with STF, after performing the DBE operation of the f32 file, I saved it back into i16 and loaded it into photoshop.  The attached image shows the result after a few non linear stretches - reminds me of an onion diagram!

[Juan Conejero]

Hi Jase,

What you're seeing is normal. A background model image is an extremely smooth function that usually requires a 32-bit format to be represented correctly. For this reason the DBE tool generates background models as 32-bit floating point images by default.

A screen transfer function in PixInsight is a 16-bit histogram transformation applied to generate the screen rendition of the image, which only has 8 bits per color channel. Clearly there is *no way* you can see a DBE model without posterization on the screen. Some models will exhibit more posterization than others, and some will look really ugly, depending on their complexity and on the smoothness of the sky gradients represented. The 16-bit histogram resolution is becoming a problem in PixInsight for screen renditions, especially as we do more and more HDR work (where we sometimes have to work with 32-bit integer or 64-bit floating point images). In a future version of PixInsight histograms will be generated with 20-bit resolution as an option (1048576 levels, or 16 times more levels than a 16-bit histogram).

The DBE model has no posterization at all. It is a linear 32-bit floating point image where finding 10^6 distinct discrete values is not unusual. You can verify this easily:

- Click the little blue triangle in the bottom bar of PI's main window and select Normalized Real Range > 1e-07. Now you are getting real pixel readouts with seven decimal digits.

- Open the ScreenTransferFunction tool and select the DBE model image.  Apply an automatic stretch or, much better, adjust STF manually (the statistic properties of DBE models are not very well suited for the automatic screen stretch function).

- Now zoom the image 10:1 or more. Identify the posterization steps. They are large regions of the image on the screen with constant color. Actually, they are not constant at all in the model image: click on the image and move the cursor over one of these posterized areas, watching the pixel readout values. They change rapidly as you move the cursor.

If you are still not convinced, I can tell you how to compute the total number of discrete pixel values in a floating point image with a script in PixInsight.

Open in Photoshop, start stretching with curves etc...

In the case of that application, posterization will not only happen on the screen rendition of the image; that application is unable to work with linear data and clearly inappropriate to handle floating point images.

[Juan Conejero]

Jase,

I've made a quick&dirty test with your image and there is no posterization at all:

http://forum-images.pixinsight.com/20111201/DBE/01.jpg

Of course, the image has to be converted to 32-bit floating point format before subtracting the DBE model. This operation cannot be performed in 16-bit format because the model has variations in the 1e-7 range; that's why you're getting posterization.

In fact, this DBE model should be generated in 32-bit integer or 64-bit floating point format; it is clearly exceeding the range of 32-bit floating point. You can select the output sample format in the DBE tool, in the Model Image section. Note that if you apply the target image correction with DBE (instead of doing it separately with PixelMath, as in my example) converting the image to a 32-bit format *before* using DBE is mandatory.

Isn't this example a nice demonstration that 16 bits are not sufficient in astrophotography? Even 32-bit floating point is not enough in some tasks

Hope this helps.

[jase]

Juan,

Thank you very much.  Your clear and concise explanation of the model logic makes sense.  I followed your steps and agree the model is correct.  Using the histogram transform function also confirms this by getting around the shortfalls of STF operation in a 16bit space (as initially advised by Steve)  This has helped immensely.  I believe I'm now heading the right direction again.

Thanks

[Andres.Pozo]

I would certainly like to know if you experience similar challenges with the data.  If not, what did you do to address it?
From my perspective, this is easily reproduced.
Open the tiff in PI
autoSTF it so you can see whats going on
Launch DBE and place samples as needed
apply
autoSTF the model - eekkk looks scary
autoSTF the DBE output - ekkk even scarier...

The first thing that you have to do BEFORE applying the DBE is to convert the image from int16 to float32. The int16 format has not enough precision in the dark part of the histogram for this kind of transformations. Applying a DBE on your image after converting it to 32bits renders a posterization-free image:

[jase]

Thanks Andres.  How would one go about converting it back down to i16 and still maintain the correct background? Pixelmath?  SampleFormatConversion appears to get me straight back to the start with posterization present.

[Juan Conejero]

How would one go about converting it back down to i16 and still maintain the correct background?

You cannot, unless you stretch the image. The linear image after background model subtraction requires much more than 2^16 discrete values. Once you have stretched the image with HistogramTransformation, a better redistribution of values over the available dynamic range will allow you to re-quantize the image with 16-bit resolution without *visible* posterization.

However, I don't recommend you do so. Much better if you continue all of your post-processing in 32-bit format and convert to 8-bit format a duplicate of the final image for web deployment.

[jase]

Thanks Juan.  I tried this shortly after raising the question and it worked.  Was just wondering if there was an alternative.  I appreciate where you are coming from in keeping post processing in 32bit format.  Whilst still learning the PixInsight ropes, I'll need to convert and exchange between other processing apps.

[pfile]

trust me, eventually you'll stop using those other apps