28 replies to this topic

[Jpsc01]

hi,

 

I'm running Pixinsight 1.9.3 on OSX 15.4.1

 

Mac is a 32 GB Macbook 2023 with M2 PRO

 

here is what I get after running a simple BlurX "correct only"

 

anyone would have an explanation / help ?

 

thanks

Attached Thumbnails

• 

[hyiger]

hi,

 

I'm running Pixinsight 1.9.3 on OSX 15.4.1

 

Mac is a 32 GB Macbook 2023 with M2 PRO

 

here is what I get after running a simple BlurX "correct only"

 

anyone would have an explanation / help ?

 

thanks

Which version of BXT and which version of the AI? Also, I have a MacBook M4 Pro. If you post a link to your image, can try it on my side. 

[Jpsc01]

Hi,

 

sorry forgot to mention it's BlurX 2.1.4 with AI model 4

 

would also be interested to know which model file you are using ?
​BlurXTerminator.4.mlpackage ?
​BlurXTerminator.4.mlmodel ?

 

or do you have per chance the mps version BlurXTerminator_mps.mlmodel which look to be good for apple silicon ? (I don't have this one)

 

you can find the RGB combine here

https://meteo-triado...oad/rgb.fit.zip

 

thanks and cheers

[klangwolke]

I’ve only seen those kind of results sometimes when I’ve integrated really small stacks (like 5x120) using fastintegration. Do you get this on all your stacks?

[hyiger]

Hi,

 

sorry forgot to mention it's BlurX 2.1.4 with AI model 4

 

would also be interested to know which model file you are using ?
​BlurXTerminator.4.mlpackage ?
​BlurXTerminator.4.mlmodel ?

 

or do you have per chance the mps version BlurXTerminator_mps.mlmodel which look to be good for apple silicon ? (I don't have this one)

 

you can find the RGB combine here

https://meteo-triado...oad/rgb.fit.zip

 

thanks and cheers

I get the same results as you with  BXT 2.1.4 AI Model 4. My advice at this point is to submit a support ticket: https://www.rc-astro.../submit-ticket/ Russ is usually very quick to get back to you. 

[Marcelofig]

I just tested on my Mac mini M4 Pro, default settings in BXT, and I get the same results.

 

By the way, why a .fit, in PI you are only supposed to work with .xifs, did you test what happens with a .xisf ?

 

And did you ask Russ at RC-astro.com ? It would be interesting to know what he has to say.

[Rostokko]

It seems to be related to the signal histogram being a very, very narrow strip.

If you stretch it first (even just the stf), then bxt is good.

Got a similar result with SetiAstro's cosmic clarity.

[Jpsc01]

That's really interesting,

 

A friend with a PC + CUDA Nvidia did the test and he got a normal result

 

this RGB is 15 x R + 15 x G + 15 x B and BlurX (correct only) has to be applied on linear one, which means I should not have such bad result

 

yes, ticket opened 12 hours ago

 

cheers

[Jpsc01]

I just tested on my Mac mini M4 Pro, default settings in BXT, and I get the same results.

 

By the way, why a .fit, in PI you are only supposed to work with .xifs, did you test what happens with a .xisf ?

 

And did you ask Russ at RC-astro.com ? It would be interesting to know what he has to say.

R G and B were stacked with APP as I'm usually doing

Edited by Jpsc01, 18 May 2025 - 02:26 AM.

[hyiger]

It seems to be related to the signal histogram being a very, very narrow strip.

If you stretch it first (even just the stf), then bxt is good.

Got a similar result with SetiAstro's cosmic clarity.

Correction and deconvolution should be done on linear images. I think clearly there is something going on with the Mac version of BXT AI, I tried the same on Windows and it's OK. 

 

That's really interesting,

 

A friend with a PC + CUDA Nvidia did the test and he got a normal result

 

this RGB is 15 x R + 15 x G + 15 x B and BlurX (correct only) has to be applied on linear one, which means I should not have such bad result

 

yes, ticket opened 12 hours ago

 

cheers

Yup, I also confirmed it works fine on Windows. Please report back here what Russ says about it. 

Edited by hyiger, 18 May 2025 - 09:28 AM.

[hyiger]

R G and B were stacked with APP as I'm usually doing

I also do all of my stacking with APP. It's around 6-7x faster than WBPP on a Mac. 

[Jpsc01]

Correction and deconvolution should be done on linear images. I think clearly there is something going on with the Mac version of BXT AI, I tried the same on Windows and it's OK. 

 

Yup, I also confirmed it works fine on Windows. Please report back here what Russ says about it. 

same analysis here,

ticket raised yesterday

 

looks like we really need to get the PI ARM version asap as it should give access to Apple Neural Engine or Metal...

[hyiger]

I just tested on my Mac mini M4 Pro, default settings in BXT, and I get the same results.

 

By the way, why a .fit, in PI you are only supposed to work with .xifs, did you test what happens with a .xisf ?

 

And did you ask Russ at RC-astro.com ? It would be interesting to know what he has to say.

Won't make any difference with .fit versus .xisf. It's linear data, i.e. it's just photo counts per pixel. 

[pfile]

same analysis here,

ticket raised yesterday

 

looks like we really need to get the PI ARM version asap as it should give access to Apple Neural Engine or Metal...

russ's stuff already uses both. no need for the ARM version of PI.

 

rob

[Dean J.]

That's really interesting,

 

A friend with a PC + CUDA Nvidia did the test and he got a normal result

 

this RGB is 15 x R + 15 x G + 15 x B and BlurX (correct only) has to be applied on linear one, which means I should not have such bad result

 

yes, ticket opened 12 hours ago

 

cheers

I just tried your data with my M4 Max Mac Studio and I got the weird result as well.

 

My data works fine with BlurXTerminator.  So its something unique or unusual about your data that is creating this result.

[JimCase]

I have a 2019 MacBook PRO (INTEL) and have seen this a couple of times running BlurX (ver 2.0.0 ) with PixInsight 1.8.9-3 on data stacked in APP. I just ran this one from March again to illustrate the problem. Might there be some issue with APP stacked data? I have used it with APP stacked data often and only seen this occasionally. 

Attached Thumbnails

• 

Edited by JimCase, 18 May 2025 - 11:51 AM.

[Dean J.]

R G and B were stacked with APP as I'm usually doing

OK, my data was calibrated, aligned and stacked with PixInsight.

[Jpsc01]

the issue we see here is clearly an overflow of an hardware stuff with the wrong driver/code

 

the BlurX which is working per block is dropping on each block like a "malloc" issue

 

this is clearly because of the lack of support of silicon +/or neural engine.

 

anyway, the good news is the ticket is raised with the RGB file in attachment so Rc-astro's DEV would be able to investigate 

[Dean J.]

the issue we see here is clearly an overflow of an hardware stuff with the wrong driver/code

 

the BlurX which is working per block is dropping on each block like a "malloc" issue

 

this is clearly because of the lack of support of silicon +/or neural engine.

 

anyway, the good news is the ticket is raised with the RGB file in attachment so Rc-astro's DEV would be able to investigate 

What happens if you do all of the calibration, alignment and stacking in PixInsight and then run BlurXTerminator rather than importing from APP?
 

Edited by Dean J., 18 May 2025 - 12:26 PM.

[hyiger]

the issue we see here is clearly an overflow of an hardware stuff with the wrong driver/code

 

the BlurX which is working per block is dropping on each block like a "malloc" issue

 

this is clearly because of the lack of support of silicon +/or neural engine.

 

anyway, the good news is the ticket is raised with the RGB file in attachment so Rc-astro's DEV would be able to investigate 

RC-Astro's dev is Russ. 

Edited by hyiger, 18 May 2025 - 12:44 PM.

[hyiger]

What happens if you do all of the calibration, alignment and stacking in PixInsight and then run BlurXTerminator rather than importing from APP?
 

That really shouldn't matter. It's a linear image. Whether it came from PI WBPP or AstroPixelProcessor should be immaterial and (in my case) I definitely would not want to give up having to use APP in order to use BTX.

[hyiger]

russ's stuff already uses both. no need for the ARM version of PI.

 

rob

I would definitely want and ARM version of PI (which is currently in development). This will speed up everything not just the exterminators rather than running in Rosetta Intel emulation. 

 

From the PixInsight 1.9.3 release notes:

The integration of V8 will also allow us to release the first PixInsight version with native support of Apple Silicon (arm64) architectures. We already have a version of PixInsight with V8, which can run basic scripts, mostly generic JavaScript code. We expect to complete the V8 integration in early summer, but it's still too soon to say anything definitive.

Edited by hyiger, 18 May 2025 - 12:50 PM.

[Dean J.]

That really shouldn't matter. It's a linear image. Whether it came from PI WBPP or AstroPixelProcessor should be immaterial and (in my case) I definitely would not want to give up having to use APP in order to use BTX.

Well, you would think that it should not matter, but it does.  My own data runs fine with BlurX but I get that weird result with the OP's data.  So there's something different about the OP's data that is causing problems and one of the differences is that the OP's data was imported from APP.

[hyiger]

Well, you would think that it should not matter, but it does.  My own data runs fine with BlurX but I get that weird result with the OP's data.  So there's something different about the OP's data that is causing problems and one of the differences is that the OP's data was imported from APP.

Agree in principle that there is something interesting with regard to the OP's data and BlurExterminator. That said I've been using APP across different scopes and cameras for several years, importing into PI and running BXT without ever experiencing an issue. So I'm sure the OP has run into an edge case that Russ will need to run through the neural nets to properly train them so it doesn't happen to others. Using a different stacker is not a viable option. 

Edited by hyiger, 18 May 2025 - 01:04 PM.

[pfile]

the issue we see here is clearly an overflow of an hardware stuff with the wrong driver/code

 

the BlurX which is working per block is dropping on each block like a "malloc" issue

 

this is clearly because of the lack of support of silicon +/or neural engine.

 

anyway, the good news is the ticket is raised with the RGB file in attachment so Rc-astro's DEV would be able to investigate 

 

no, no, and no.

 

not a wrong driver, there is no such thing as the wrong driver on OSX. it is not a malloc issue. it is not because of lack of support of apple silicon. just open up activity monitor and bring up the GPU history window and watch what happens when you run any of his tools on OSX. some of his models use the neural engine but most of them use Metal on the GPU.

 

i think behind the scenes BlurX has to stretch the image, apply the sharpening, and unstretch the image. there is probably something funny about the histogram of this image that is messing up the reversable stretch. this tiling thing is actually how blurX works behind the scenes and its under pathological conditions like this that you end up seeing the tiles. by the way the "large overlap" control changes how the tiles are segmented.

 

 

 

I would definitely want and ARM version of PI (which is currently in development). This will speed up everything not just the exterminators rather than running in Rosetta Intel emulation. 

 

From the PixInsight 1.9.3 release notes:

yes of course everyone wants this. i'm not saying that an ARM version of PI is not necessary, on the contrary it is super important. someday apple will dropp support for Rosetta2 and that will be that for PI unless there is an ARM version. what i meant was is that OP is just talking through his hat - Russ's tools already most definitely make use of Metal/the Neural Engine and that has nothing to do with this problem.

 

 

rob