StarTools

Hmm, I dunno. At least it's something to explain the black box, I guess.

My math skills are similarly challenged, despite my 80's-era minor degree in it. I mean I recall when Ivo and maybe Dietmar or Stefan were trying to explain digital filtering to me. I still don't quite get it.

Anywho, it seems he is laying out the basics, but I can't tell if he is thereafter just piling on the word salad in order to provide cover for what BXT is doing.

Also, if one is sampling, which SVD does and which he claims BXT is doing via tiling, doesn't that mean it isn't blind deconvolution, or am I misunderstanding that term?

Still seems to be it's what Ivo said it was way back. A sharpening or deblurring single pass, even if locally sampled, creating plausible but unreal fine detail, coupled with a repainting of stars (and the occasional small galaxy, apparently) into perfect little circles.

The too good to be true star results strike me as telling, though maybe I just don't understand it all. I mean people are posting up perfect stars that started out horrendously mangled for all sorts of possible underlying reasons. Now, maybe perfect deconvolution could actually undo even normal diffraction, taking stars to a point source with the surrounding pixels properly reconstructed, but doesn't noise prevent that no matter how deep the stack? And since that's the case, just what is being filled in around these newly-rounded and coalesced BXT stars? Almost seems to be like the star removal problem -- you didn't acquire what was there (it was blocked, after all) and so have filled things in with fake interpolation.

Maybe I'm wrong there to the extent deconvolution is true reconstruction, but can BXT really be that, or is it a deepfake?

Croman did reply again to say:

BXT was trained to perform deconvolution on linear data with stars present to infer the PSF*, and with no noise reduction applied prior to its use. What it does to nonlinear data, or data without stars, or data that has been noise-reduced by who knows what method, is anyone's guess. The only thing I can say with confidence is that the results cannot be called deconvolution. I can't stop anyone from misusing a tool, but I also feel no obligation to support it.

Which is interesting. I will have to pay more attention to where in the process people say they are applying BXT.

@Mike in Rancho have you read Shaun's Experienced Imaging thread about his "convolve then deconvolve" experiment? There was discussion from Rista about noise profiles (I guess so, because you thought Shaun's new thread was about the M101 data).

Anyway, I expect you're right that applying SVD to the convolved image may not be proper, but I thought I'd post it anyway. I think the simple take-home message most readers of Shaun's "results" thread would be "hey look how awesome BXT is!". I have long suspected that either PI's deconvolution isn't very good, or, much more likely, the PI implementation is so complex and fiddly that very few users get anything like the best results from it. I wouldn't say that publicly, because I have no first-hand experience with PI's implementation (this isn't a public place, right? ).

Maybe someday we can get a side-by-side BXT/SVD on a single dataset, done by someone really good at both PI and ST.

dx_ron wrote: ↑Sat Feb 10, 2024 10:53 pm @Mike in Rancho have you read Shaun's Experienced Imaging thread about his "convolve then deconvolve" experiment? There was discussion from Rista about noise profiles (I guess so, because you thought Shaun's new thread was about the M101 data).

Anyway, I expect you're right that applying SVD to the convolved image may not be proper, but I thought I'd post it anyway. I think the simple take-home message most readers of Shaun's "results" thread would be "hey look how awesome BXT is!". I have long suspected that either PI's deconvolution isn't very good, or, much more likely, the PI implementation is so complex and fiddly that very few users get anything like the best results from it. I wouldn't say that publicly, because I have no first-hand experience with PI's implementation (this isn't a public place, right? ).

Maybe someday we can get a side-by-side BXT/SVD on a single dataset, done by someone really good at both PI and ST.

For that dataset, I got best results just using a synthetic PSF (Moffat 5.0). The problem is that Shaun's dataset was blurred after acquisition, which blurs singularities (like overexposed stars) as wel) yielding incorrect information in that local area. To StarTools these look like "valid" stars with "soft" cores that you may sample, while in reality they are very poor candidates for sampling.

dx_ron wrote: ↑Sat Feb 10, 2024 10:53 pm @Mike in Rancho have you read Shaun's Experienced Imaging thread about his "convolve then deconvolve" experiment? There was discussion from Rista about noise profiles (I guess so, because you thought Shaun's new thread was about the M101 data).

Anyway, I expect you're right that applying SVD to the convolved image may not be proper, but I thought I'd post it anyway. I think the simple take-home message most readers of Shaun's "results" thread would be "hey look how awesome BXT is!". I have long suspected that either PI's deconvolution isn't very good, or, much more likely, the PI implementation is so complex and fiddly that very few users get anything like the best results from it. I wouldn't say that publicly, because I have no first-hand experience with PI's implementation (this isn't a public place, right? ).

Maybe someday we can get a side-by-side BXT/SVD on a single dataset, done by someone really good at both PI and ST.

I sort of read that first thread in EDSI, but not to completion. I actually downloaded that first file from Shaun's share before Rista even joined in, IIRC. And it thoroughly confused me.

The file was huge, honestly not all that great considering it apparently was purchased from Chili, and then Shaun went and blurred it. In that first link, I don't recall the base file being provided.

So on this new post I assumed it was the same M101 again. Oops! After checking the readme, it seems that now we have multiple files to work with including maybe the linear original? Shaun's descriptions still baffle me though - he keeps talking about "his" image and image scale. What that has to do with the purchased data I have no idea.

Anyway on that (semi horrible) M101 I kept it at original scale, did a wipe and O/D, then just SVD in 1.9b. Things took a while on my old rig considering the file was 9000x6000. SVD did not come up with great sampling, and the end results had terrible uncorrectable ringing. I thought about re-trying in 1.8, since there we can control the apod mask for both sampling and deringing support, but 1.8 is too slow for that file size I think.

Anyway I only half-followed the thread after that. Here with this new one, it seems there's better data for testing, and as far as I can tell (haven't opened anything yet) he has provided an original stack, his artificial blurring of it, and then a PI deconvolve and a BXT...whatever it is that BXT does. Are they all linear? I guess I will find out.

Theoretically we could probably do this in ST as well. I don't know if this file will require actual Wipe gradient extraction (or if we even have to use it, this just being an L file), but if we just run that and O/D, followed by SVD, we should be able to restore it to linear/wiped/deconvolved, right? And that way we can give back a linear file that is only deconvolved, which can then be autostreched or GHS'd in PI or Siril etc.

The only potential snag being that ST can only output a 3-channel RGB TIFF, as far as I am aware. No mono, no FITS. Something else could probably convert it.

admin wrote: ↑Sun Feb 11, 2024 1:08 am For that dataset, I got best results just using a synthetic PSF (Moffat 5.0). The problem is that Shaun's dataset was blurred after acquisition, which blurs singularities (like overexposed stars) as wel) yielding incorrect information in that local area. To StarTools these look like "valid" stars with "soft" cores that you may sample, while in reality they are very poor candidates for sampling.

Ah, interesting. I replied back to Shaun that I was concerned about the artificial blur he imparted and how that might affect testing validity, but that was just a hunch (not like I know what I am talking about).

I haven't gone back to CN yet, but I did see that he was thinking the added blur is just another factor that would result in the final PSF, similar to any acquisition. Wasn't sure how to consider that or respond yet.


Still, if these are linear FITS, he has given us an original plus a PI and BXT file. I wonder if we can use the Dietmar Viewers to see what BXT did?

In case anyone is still following and maybe doesn't follow CN, I added a few collages over there of stretches and other tools run on the data, starting here: https://www.cloudynights.com/topic/9104 ... ry13258130

These are based on a couple threads by Shaun (sbharrat on CN) in EDSI and BDSI regarding experiments he was trying to devise to evaluate deconvolution and (mostly) BXT. In short he was using purchased data, this time of Cent A. It is luminance only. I actually find it pretty nice, apart from many overexposing star cores. Shaun then came up with an artificial PSF to convolve (blur) that file, and the experiments were to see how different programs might be able to recover from that blur (and the original unblurred file would be on hand for comparison).

Shaun provided links to the original stack, his artificial blur thereon, as well as attempts to recover using PI deconvolution, and BXT. All files were linear 32-bit.

In both CN forums some snags were pointed out regarding the validity of the experiments.

Still, I thought it would be interesting to throw ST (and Siril) into the mix. But, after something goes through ST it can only come out as 16-bit RGB TIFF, even if reverted to linear, compared to all the others at 32-bit mono FITS. And those end up autostretching differently. So I tried to use a matching OptiDev on each file to get reasonably close stretches for comparisons.

The attribution of the data provided by Shaun is:
- Purchased from the photographer Matt Dieterich
- Taken with PW CDK24 and FLI Proline 16803 in Chile (https://www.mattdiet...h.com/centaurus)
- This is luminance only, 80m aggregate exposure

If anyone wants to pixel peep the results (zoom the view), I put them all in a Gimp project file in multiple layers. So you just have to click the layer view button in order to blink back and forth between chosen versions. The ones with just L are based on the original stack. The ones that say L_conv are based on the artificial blur Shaun imparted.

On the blurred file as a starting point, Shaun provided deconvolution (RL) in PI, and also ran BXT on it. As to both the original and blurred, I ran SVD, and also tried some wavelet sharpening and even Siril RL deconvolution. On the blurred file I also ran SVD in synthetic mode. Finally, for the blur version with sampled SVD, and based on Ivo's remarks, I tried to choose samples made from smaller stars and not saturated stars where the blur would make SVD's sampling color mapping think bad stars were in fact good candidates.

Curious what everyone might find - good, bad, or confounding - in the images.

https://drive.google.com/file/d/16MYJmW ... sp=sharing

I've enjoyed the discussion on this thread but would simply say that if you try Blur Xterminator and like the results, why analyze it?
If you don't like the results that's fine too.

In the end astrophotography is fairly reliant on creativity and the image you end up with will be quite different from mine even if we use the same data.

astroimagery wrote: ↑Sat Jul 13, 2024 12:07 pm In the end astrophotography is fairly reliant on creativity and the image you end up with will be quite different from mine even if we use the same data.

The goal of documentary photography is to be the least reliant possible on creativity, and the most reliant on what has been captured.
Using the same data, two image processors should be able to draw the same conclusions on what the data represents.
If we end up with different images, it should be possible to articulate why we did so. "Because it looked cool" is not a well articluated reason, but "because I wanted to highlight the O-III in that area" is.

Drawing the borderline between astrophotography and painting seems to be hard. I think, in photography, "creativity" should be limited to the techniques used by image processing, but not be "creativity" in terms of the subject rendered. This should always root in real data, else it would be "painting", not photography. That is not to say, painting would not yield great results, it's just a different thing painting Mona Lisa or doing portrait photography....