Author Topic: Screen transfer function  (Read 2911 times)

Offline m_abukhalid

  • Newcomer
  • Posts: 23
Screen transfer function
« on: 2018 January 27 09:19:15 »
Hello,

Im was trying to experiment with the histogram transformation function to try to learn how to manually stretch my image when I discovered an anomaly with the screen transfer function. I've been using the STF button in the toolbar throughout my preprocessing, followed by DBE, background neutralization, photometric color calibration and finally SCNR. My stacked image had a wierd dark blotch (seen in all the attached screenshots) but it seemed to be largely mitigated in the color calibration step.  Does anyone know what would cause the wierd dark blotch? In retrospect, I did stack 2 sets of data with slightly different exposures (f2.8 and f3.2) which reading online should have been stacked separately and merged using HDR transformation...

My questions are:
1) If I have various images (say 100 per) at the same focal length, but varying aperture or ISO settings, can they be registered and stacked together or should they be stacked separately and merged using HDR transform?
2) Currently in my image I am seeing an odd variation in the STF function output (see attached screenshots). The better one is the result I got from using the automatic STF button in the background neutralization step, saving and then just applying color calibration and SCNR with it still on. when i save and reopen the image, that is what I see in pixinsight by default. However if I clear the reset the stretch and use the STF function itself, I get the attached results RGB channels linked/unlinked? Why are they different? How do you replicate the stretch I got the first time around?

Thanks in advance for any help and advice...
Mohammed

Offline John_Gill

  • PixInsight Old Hand
  • ****
  • Posts: 368
Re: Screen transfer function
« Reply #1 on: 2018 January 28 22:22:59 »
Hi,

I had something similar and it turned out to be a smudge of dirt on the camera sensor.  Perhaps clean all the optics and then take a few images of a plain dull sky background or similar and look at the results carefully.

Hope this helps
Look up
John
APM 107/700 apo on CGX mount
ZWO Optics - Autoguiding
ZWO1600mm and filters
... when there are no clouds ...

Offline ngc1535

  • PixInsight Old Hand
  • ****
  • Posts: 326
Re: Screen transfer function
« Reply #2 on: 2018 January 28 23:12:47 »
Pretty complex questions... but heck, I am fearless...

Hello,

Im was trying to experiment with the histogram transformation function to try to learn how to manually stretch my image when I discovered an anomaly with the screen transfer function. I've been using the STF button in the toolbar throughout my preprocessing, followed by DBE, background neutralization, photometric color calibration and finally SCNR. My stacked image had a wierd dark blotch (seen in all the attached screenshots) but it seemed to be largely mitigated in the color calibration step.  Does anyone know what would cause the wierd dark blotch? In retrospect, I did stack 2 sets of data with slightly different exposures (f2.8 and f3.2) which reading online should have been stacked separately and merged using HDR transformation...

Concerning the dark blob (I see two of them I guess)- If you perform the automatic screen stretch on your raw data, is it there? If not, it is a processing issue.  DBE can cause this effect if you choose a sample that is actually a star (and you are using a permissive tolerance setting). Just an example I can think of... but something on the optics is certainly the most likely if in the original images.


My questions are:
1) If I have various images (say 100 per) at the same focal length, but varying aperture or ISO settings, can they be registered and stacked together or should they be stacked separately and merged using HDR transform?

There isn't an issue with combining images from different focal lengths and apertures. This comes out properly (although there are potential mismatches in resolution and optical aberrations that can make aligning and combining them troublesome. The harder one (and I do not know the math) is dealing with different cameras or ISO settings. I suspect both of these require the proper treatment of the gain factors. It could be PI takes care of this automatically. Not certain. Assuming this stuff is OK- then PI will take care of the weighting for the data. I do not think HDR is required. So for this question, I am on shaky ground.

2) Currently in my image I am seeing an odd variation in the STF function output (see attached screenshots). The better one is the result I got from using the automatic STF button in the background neutralization step, saving and then just applying color calibration and SCNR with it still on. when i save and reopen the image, that is what I see in pixinsight by default. However if I clear the reset the stretch and use the STF function itself, I get the attached results RGB channels linked/unlinked? Why are they different? How do you replicate the stretch I got the first time around?

Before #2 can be answered (if I understand the question...)- I think it needs to be checked off that there is an understanding that the STF process is just a visualization tool and it does not change the underlying data.  So when you click the automatic screen stretch it will display data in exactly the same way (unless you change the parameters for how the algorithm works) each time you press that button.

Now if I understand the question- you performed some changes to your image (like color calibration and such). What you are seeing on your screen is the STF stretch you get being applied to new data (numbers in your image)  with the old STF settings. This is not the same as recalculating the automatic STF for the newly processed image.

1. You applied auto STF... you like your image.
2. You did stuff to your image (color calibration, SCNR..etc)
3. **Did you press the auto STF again to update/recalculate for your newly processed data?**
4. You saved.
5. You reopened the image... and pressed the auto STF and it looks different. But this is just because it is the first time you have recalculated and displayed for the new version of your image. Step #3 and Step #5 should look the same. If not... well... then something in the save step. Step #3 is the thing that has bitten me before because I thought I was looking at the image at a particular contrast level... and it turns out it was not what I was expecting because I did not update by pressing the auto STF again.

 I should add that you can adjust the levels (shadows, midtones, highlights, target background..etc) of the STF process to get close to what your original data looked like. But after processing you literally have a new image- and there isn't necessarily a way to automatically know what parameters when applied to the newly processed image will make it look like the old image- it depends on the processing. Users just make the adjustments manually as you will need to do at some point when you are ready to permanently stretch (make non-linear) the image.

-adam


 


Thanks in advance for any help and advice...
Mohammed

Offline bulrichl

  • PixInsight Guru
  • ****
  • Posts: 524
Re: Screen transfer function
« Reply #3 on: 2018 January 29 02:35:03 »
Let me add that such smudge of dirt will be visible more clearly when stopping down the lens. Not only dull sky but also blue sky (away from the sun) is well suited for this purpose.

Bernd

Offline m_abukhalid

  • Newcomer
  • Posts: 23
Re: Screen transfer function
« Reply #4 on: 2018 February 02 20:33:45 »
Thanks for the replies! The smudge as indicated by adam was caused by incorrect placement of a few sample that partially overlapped some stars... once I moved them it went away. With respect the STF... what was wierd was this:
1) worked on image and performed color calibration. reapplied auto stf, liked what I saw, saved my work and closed the image
2) next time I opened the image, when I reset the image and used auto stf I got a different result as indicated by the attached pictures (exaggerated smudge).

It is wierd and hasnt happened to me again since I redid the DBE process.

Offline ngc1535

  • PixInsight Old Hand
  • ****
  • Posts: 326
Re: Screen transfer function
« Reply #5 on: 2018 February 02 21:29:59 »
Yay! I got one right! (finally!) It is quite depressing to be wrong *all* of the time.
Regarding STF. That is puzzling to me. The only missing information is the manner in which you saved the image... but it is hard for me to imagine how that might effect you (unless you saved as a JPEG or something weird). Did you save as an *.xisf file?

One thing you might consider- is saving your work as a project. This way the image retains all of the steps you performed on the data... and will leave things in precisely the same state as you left them. Then the only things you might need to write to the disk are you final processed images.

If you figure out the STF... please do report.

Still happy about getting something right. :)

-adam


Offline m_abukhalid

  • Newcomer
  • Posts: 23
Re: Screen transfer function
« Reply #6 on: 2018 February 03 06:30:40 »
ooooh. I didnt think of that. I have a project saved with a template of my workflow and I've been saving each step of the workflow as an xisf file. This takes up a lot of space though... I will try to create a project for each image and see ... I just lost a lot of time because pixinsight crashed while I was trying to save my DBE output... so will have to start all over again :P

Offline macnmotion

  • Member
  • *
  • Posts: 61
Re: Screen transfer function
« Reply #7 on: 2018 February 03 07:16:39 »
A piece of advice. When performing a time intensive process (e.g. DBE placing points), before executing (and possibly crashing as happened to you) save a process icon onto the workspace, give it a good name, and then save it to your hard drive. That way if you crash you can load back in your process icon, double click, and voila you're back where you were without losing a thing. This is also good practice when applying processes to one channel that you may apply later to another (e.g. dynamic crop, dbe).