StarTools 1.6.382 alpha is big; please report any issues!

[admin]

Really appreciate the feedback!
I've been replicating your log using your dataset with a (lengthy) valgrind session this morning. Painfully slow, but it completed without errors.
That most likely means we're looking at an OS-specific issue.

2019-12-07 08:51:59.867 StarTools[1918:27211] Error while swapping tracking information to disk. Tracking information has likely been corrupted. Use the Undo button to recover previous tracking information. Free disk space for your /tmp folder and try again.

This one is interesting in particular; it seems the /tmp/ folder has "randomly" become inaccessible or that the /tmp/ folder has run out of space. That's... bad.

[PaulE54]

Running the current beta. I am processing OSC data using compose, importing the same data 3 times, once as red, once as green and again as blue. Working this way I can recover FAR more detail from the same data than I could working "traditionally" in previous versions. This is a major step forward for me. Most things run quicker in this mode, but the psycho visual GE denoise maxes all cores of an i5-6500 3.2 GHz processor with 16GB memory and SSDs for around 10 mins on a 3300 x 2300 image. The resulting images are very nice though

Paul

[hixx]

Hi Ivo, thanks for testing...
Yes, the sessions are usually slow due to full-frame camera. I never had those issues before though. I cross checked with old ST versions which have the same issue: crash when a save is carried out. These issue appeared after updating to Catalina (macOS 10.15.2) However, this type of issue is not specific to ST. E.g. Pages will crash with the warning "your file could not be safed automatically". I will be reverting to Mojave this weekend and let you know whether issues disappeared. Another Catalina problem is downloading will be aborted. Again, this happened for other software as well, so not ST specific. This is due to Apple`s new firewall setting and may be worked around by disabling the firewall in System Settings/Security, then download, then enabling firewall again.

[admin]

Running the current beta. I am processing OSC data using compose, importing the same data 3 times, once as red, once as green and again as blue. Working this way I can recover FAR more detail from the same data than I could working "traditionally" in previous versions. This is a major step forward for me. Most things run quicker in this mode, but the psycho visual GE denoise maxes all cores of an i5-6500 3.2 GHz processor with 16GB memory and SSDs for around 10 mins on a 3300 x 2300 image. The resulting images are very nice though

That's great Paul! If your image was not color balanced, you can import your DSLR/OSC dataset with the second option, which will essentially do the same thing (except that it weights the green channel higher).
StarTools 1.6 definitely maxes more cores more often. However, 10 minutes for the Denoise 2 module for a ~7MP image sounds a little excessive... At which stage is this? Does it just do this once and are subsequent parameter tweaks faster?

Hi Ivo, thanks for testing...
Yes, the sessions are usually slow due to full-frame camera. I never had those issues before though. I cross checked with old ST versions which have the same issue: crash when a save is carried out. These issue appeared after updating to Catalina (macOS 10.15.2) However, this type of issue is not specific to ST. E.g. Pages will crash with the warning "your file could not be safed automatically". I will be reverting to Mojave this weekend and let you know whether issues disappeared. Another Catalina problem is downloading will be aborted. Again, this happened for other software as well, so not ST specific. This is due to Apple`s new firewall setting and may be worked around by disabling the firewall in System Settings/Security, then download, then enabling firewall again.

Thanks for the updates. The behaviour of the OS seems really quite bizarre - it really sounds like it is randomly revoking file system write access on a very low level. I've observed this on Linux systems where the OS has detected a hardware failure and places the media in read-only mode. I've seen this happen because of an actual hardware failure, as well as a device driver bug (sleep related).
It really does sound this is an OS bug. If that is the case, then it is very worrying that Apple feels it is ok to release this for daily use.

[PaulE54]

Hi Ivo.
It's once I have set the initial pixel scale and the main processing starts, on the window with the "keep" button. Having said that it was better behaved today, at around 4 mins, if for example I tweak the "grain limit color" parameter it then takes another 4 mins or so to reprocess the data with the new parameter setting.

My new IDAS NB1 nebula filter arrives today, so if the clouds ever clear, I will be working out how to process dual narrowband images taken with an OSC.
Simplistically I think this means I just load the image into compose, but only the red and blue channels.
I think I will also have a choice of palettes to render in when I get to the color module....

Paul

[admin]

Hi Ivo.
It's once I have set the initial pixel scale and the main processing starts, on the window with the "keep" button. Having said that it was better behaved today, at around 4 mins, if for example I tweak the "grain limit color" parameter it then takes another 4 mins or so to reprocess the data with the new parameter setting.

That really sounds quite long. Though your i5 is a 4-core/4-thread part, it still has plenty of grunt. Something is not right. Is you CPU overheating at all? Have you got anything open in the background? Processing times should be pretty much consistent and not vary from day to day... Regardless, have you tried working with preview areas?

My new IDAS NB1 nebula filter arrives today, so if the clouds ever clear, I will be working out how to process dual narrowband images taken with an OSC.
Simplistically I think this means I just load the image into compose, but only the red and blue channels.
I think I will also have a choice of palettes to render in when I get to the color module....
Paul

Pretty much spot-on Paul! If you used a dual-band filter, and they originate from an OSC, then you can actually load just these datasets just using the 'Open' functionality on the home screen and choose the second option (which also engages Compose mode, kind of like a shortcut). This makes the most of - in particular - the green and blue channels, as O-III and Hb will be recorded in both these channels (e.g. just using the blue channel would be "throwing away") some data.
Then, when you get to the Color module, start off with the Duoband preset and select any Color rendition (channel swap) that you like from the Matrix dropdown.

[Topographic]

When i load data (see autosave001 from getting rid of streaks topic) with the second option, the Compose button activates and cannot be switched off? Am I missing something?

[admin]

When i load data (see autosave001 from getting rid of streaks topic) with the second option, the Compose button activates and cannot be switched off? Am I missing something?

As of ST 1.5 , the second option uses Compose mode (e.g. processing color and luminance seperately). It is really a shortcut for loading R, G and B separately in the Compose module, setting Mode to "L + Synthetic L From RGB, RGB" and doubling the green channel's exposure time vs the blue and red channels. This retains correct coloring, but weighs the green channel higher for the luminance signal, as your Bayer Matrix has twice the number of green samples vs blue and red samples. The result is (should be) a slight signal boost. Of course, this only works correctly if the RGB dataset has not been white balanced or otherwise meddled with.

[Topographic]

When i load data (see autosave001 from getting rid of streaks topic) with the second option, the Compose button activates and cannot be switched off? Am I missing something?

As of ST 1.5 , the second option uses Compose mode (e.g. processing color and luminance seperately). It is really a shortcut for loading R, G and B separately in the Compose module, setting Mode to "L + Synthetic L From RGB, RGB" and doubling the green channel's exposure time vs the blue and red channels. This retains correct coloring, but weighs the green channel higher for the luminance signal, as your Bayer Matrix has twice the number of green samples vs blue and red samples. The result is (should be) a slight signal boost. Of course, this only works correctly if the RGB dataset has not been white balanced or otherwise meddled with.

Definitely missed that, so 'Linear' is for all stacked single channel images. The screen description doesn't read that way, the second option still seams the best option. No mention of using it for multi-channel processing. Perhaps an amendment of the description is necessary? Is there a readme file somewhere?

[admin]

so 'Linear' is for all stacked single channel images.

The first option is a catch all. The second option is only for datasets that were acquired specifically with an OSC/DSLR with a Bayer Matrix and that have not been white balanced.

E.g.;

• If your dataset was acquired with a mono camera, choose the first option.
• If your dataset was white balanced, choose the first option.
• If your dataset is some sort of composite, choose the first option.
• If your dataset is from a DSLR that uses an alternative color filter array (e.g. not a Bayer matrix), choose the first option.

Etc.

Does this help?