Donut stars

[decay]

One addition: Here's a screenshot of the stretching tool that FITSWork offers:

2024-03-28 11_47_44-Fitswork.jpg (54.1 KiB) Viewed 9184 times

My understanding is, that OptiDev works likewise, but the points are calculated, like Ivo described. The curve is interpolated between the points. And while the old beta used 4096 points the new version uses 65536 of them(!). I would assume, that even 4096 points are not necessary? Maybe there's still something that I don't understand And how is it possible/reasonable to calculate an estimation for the detail/entropy contained within such a small slice? Besides of the fact that we probably cannot perceive such fine graduated detail at all?

[decay]

Oh, I think, I have a run Last post for today. But I would like to go back to my first diagram. Maybe it's clearer now what is depicted: These two curves are the stretches produced by the old beta and the new beta version. Everything else was identical: the image and the processing. Same BIN, CROP and WIPE and the same settings in OptiDev.

How is this difference possible? Only because of the increased resolution of the stretching curve?!

I hope nobody will start throwing stones at me

[Mike in Rancho]

Hey Dietmar,

Thanks for the remedial histogram lession.

I think I was confusing the input/output mapping line with the tally-up pixels at all the brightness levels line.

I for sure wouldn't mind trying out the reader app to then make some graphs in a spreadsheet. Maybe try to get an idea of what is happening with some sample astro photos and also perhaps synthetic images.

I still need to get out a yellow pad to try to sketch out the whole tranches and expanding/compressing dynamic ranges idea.

I am perhaps surprised too that your one "zoom" chart has some angled bends. Even "only" 4096 slots seems like a lot. But, if you can see those without being very deeply zoomed, that may represent regions of...compression? (hope I didn't get that backwards).

Having 2^16 tranches now is interesting though. The smoother curve seems to follow, yes. But, how do you expand or compress 65536 tranches when that's the number of brightness levels anyway, unless things are being combined? Isn't that 1:1? Or is it because the stacks started out as (usually) 2^32, and ST is able to expand and compress that? But, the save-out is only 2^16 TIFF, and that is what your app will be reading.

Yes I've confused myself even further. Atmospheric river coming this weekend, so maybe I can get my head around it then.

[decay]

Mike, I think now we are on the right track. If you are interested and we both think the app can be useful to try out things and to get a better understanding, I will be glad to share it. But first I have to bring it into a no-nerd usable state.

I still need to get out a yellow pad to try to sketch out the whole tranches and expanding/compressing dynamic ranges idea.

We should clarify this before going ahead. I would suggest, we both should re-read Ivo's explanations and maybe above FITSWork graph can help us to sketch some examples. One hint already now: allocation of a high dynamic range / bringing out much detail / high contrast causes to curve to have a high inclination at this range, inclination > 1 / 45 degrees. If there's no or little dynamic range allocated, this part of the curve is more horizontal aligned.

We should have a look at your other points/questions afterwards, step by step. I suppose these are important for us to clarify. As said, I'm also not sure about this high number of 'slots'. Maybe still a misunderstanding?! But I don't think so

[decay]

Mike @Mike in Rancho

https://c.web.de/@334960167135216273/rX ... z62YiKT7Sw

Please create a local folder and copy the files into it. Open up a console window and navigate to this folder. You can run the tool by typing 'StretchTransformCurveAnalyzer'. No params yet. It expects 'pre.tiff' and 'post.tiff' images to be named exactly this way. Output is written to 'stretch.csv' and 'hist.csv'. 'hist.csv' contains the histogram data; first column brightness value, second column 'pre.tiff' data and the third column 'post.tiff' data. Existing files are overwritten without notice. In case of errors you will get funny exceptions and stacktraces As said, just a quick hack by now.

I would suggest to use some more field-filling data, not such a small galaxy.

Let me know, how you get on!

@all: this is ST forum and not Mike's and Dietmar's private chat. Participation is very welcome, of course!

[decay]

Hi Mike @Mike in Rancho please use with caution - I found a problem. As I wrote, when applying a global stretch, each brightness mapping should be unique. But it isn't. I just implemented a check. I should have done earlier.

The differences are quite large, for example:

13412 - 12870
13412 - 13296
13412 - 12582
13412 - 12716
13412 - 13440
13412 - 12827
13412 - 12672
13412 - 12968
13412 - 13002
13412 - 13147
13412 - 13260
13412 - 13090
13412 - 13326
13412 - 12640
13412 - 12556
13412 - 13547
13412 - 13326
13412 - 12699
13412 - 13498

This is way too much to be explained by rounding errors?! This would mean, that OptiDev does not only do a global stretch, but something more. I will have to think it over.

But even worse, I found mappings where the output value is 0. So a high brightness of for example 6417 is mapped onto 0 - which is black in our post-stretch image. I will have to check the concrete pixels. Something is wrong

[Mike in Rancho]

Hi Dietmar,

Cool! But, problem with the app, or problem with our understanding what is going on? Or both

If you want to DM a link I suppose I could review the project. Maybe? I have VS 2022, not sure if that's what it is in. There was one time I traced and debugged a critical project, and my employer gave me a -- letter of commendation!

Of course that was the early 90's...

Off to work though, can't download and try things out until late tonight.

[dx_ron]

@all: this is ST forum and not Mike's and Dietmar's private chat. Participation is very welcome, of course!

Shh! Mike and Dietmar are trying to talk here!

(and I want to know more about what's going on in the "obscene-drinkingcheers" emoji)

About Mike's question regarding how one starts with 65,556 possible values and remaps them onto the same number of output values - you just have to think about it the right way.

If you find that brightness values in the range 900-1000 "deserve" more of the (visible) dynamic range, you first decide how much. Let's say you want the 100 linear values to be remapped to occupy 1000 output values. Say the new range will be 600-1600. Take all the (linear) pixels that fall into 1001-65,565 and recalculate each so they now fall into the smaller range 1601-65,565. Some individual pixel values will have to be combined - that's what "reducing dynamic range" means. I assume you'd want to space those combined values out, so maybe any pixels with original brightnesses of 1825 & 1826 are now combined into a single brightness. Maybe its 2583 in the stretched image. Then you'd combined some other non-contiguous pixel values into one, and so on until you've redistributed 1001-65,565 into its new, smaller, range. In the curve, the 900-1000 (linear) region would have a slope ~10 while the 1001-65,565 region would have a slope <1

I wonder if there will, in the end, be enough information in the reconstruction of the remapping to really determine what the new stretch curve is. I suppose maybe 26 million sample points is enough...

[decay]

As I wrote, when applying a global stretch, each brightness mapping should be unique. But it isn't.

But, problem with the app, or problem with our understanding what is going on? Or both

Maybe a bit of both. But it isn't too worse. Thinking a bit deeper, it is quite clear, that saving as 16-bit TIFF causes a kind 'quantization'. And especially with aggressive stretching (high dynamic range) a single brightness level of the pre-image is mapped onto a range of levels in the post-image. Because the single brightness level of the pre-image consists of multiple levels which can't be saved into this 16-bit TIFF.

I enhanced the tool to calculate average values. The output CSV now contains 5 columns: input brightness level, average output level, min level value, max level value and average sample count.

I've uploaded the new version of the tool into the shared folder.

Off to work though, can't download and try things out until late tonight.

Yes, Thursday I had a day off and Good Friday is a public holiday here in Germany. So I was able to spend a few time on this. But I probably can't the next days. Another project needs some time too and yeah - my family expects me not to spend all the time working on silly astro-projects during Easter weekend

But I'm looking forward to what we can find out. It looks quite neat now.

I wonder if there will, in the end, be enough information in the reconstruction of the remapping to really determine what the new stretch curve is.

I'm still not sure as well, Ron. But actually it doesn't look too bad ... at least this is what I'm thinking right now

Best regards, Dietmar.

[decay]

If you want to DM a link I suppose I could review the project. Maybe? I have VS 2022, not sure if that's what it is in.

I've uploaded the whole VS solution into the shared folder, too.