StarTools

After years of loving using ST, (2013!)
I still realise that i do not understand some things.

This topic is about saving files part way through the process.
For example, lets say i load a linear osc file via open or compose, then autodev, bin, wipe, contrast and hdr.
If i save the file then, what is it saving? has the data actually been stretched, and that non linear stretch is saved including the adjustments? What has happened to the colour, is the file still a colour three channel file or is only the luminance saved?
What about after decon? Does a saved file then have the decon applied. Again, is it just a luminosity file?
Any insights are gratefully welcomed.
Asking for a friend lol

Andy

Hi Andy,

The save functionality saves the image as-you-see it. What you see is what you get, very much like other programs.

You can use the Restore button/functionality to save different states of the image however.
For example, if you need to, you can use the Restore functionality, to restore the image to a linear, deconvolved state and save that. You can then click undo and keep on processing.

StarTools internally keeps track of the entire signal processing flow, which it can collapse into different "images" (linear, non-linear, with decon, without decon, with certain detail enhancement, without certain detail enhancement, etc.) at any time as needed. It uses these different "images" to process, measure or isolate different aspects of the signal.

The restore functionality/button collapses the recorded signal flow into specific images.

So, StarTools itself very much does not use the image as-you-see-it, which is the big difference with any other software (that I am aware of); other software typically just uses the "image-as-you-see-it" to apply the next filter or step (simple screen stretches not withstanding).

Recording, per-pixel, how the signal evolves, is also the reason why StarTools produces such huge files (the .trk) files. The size of these files, which easily can run into multiple GBs, has made it prohibitive to keep multiple save-states around. This is the prime reason why why saving of the full workflow and signal evolution mid-processing, then closing StarTools, and coming back later, has not been possible (yet).

Does this help?

Hi Andy,

Good question. I am interested in hearing Ivo's response myself.

My current understanding/testing is this -- it all depends.

If you use compose, or open with middle option, any saves done after that will be luminance only. Whether it is linear or not depends on what you have done, module-wise, to get to the point where you use the save, pre Color module. Post auto-dev, no, it will be stretched. But as far as I know, all processing you've implemented will end up saved. Post color module if you hit keep, there will be indeed be color.

If you open with left option, however, you will process through in color, and thus your saves will be also.

I believe ST saves are 16-bit RGB TIFF. I am uncertain of other options and how they work. I believe you can also type .jpg and maybe even .png to save in those formats. The 16-bit RGB TIFF save holds true even if you are saving from the luminance mode as discussed above, but all pixels will have the exact same value for R, G, and B. I'm not sure if that counts as formal "grayscale," but it would seem to me the effect is the same.

My extra question on top of yours is this, however -- say one is doing various channel stripping and composing, which ST is good at and is described oft in the guides and notes. Many of those require a save, and if done right, it can still be linear, which is often what you need. But, considering that you started with (likely) a 32-bit FITS, perhaps integer or perhaps FP, are we losing depth of detail when we do this, as we will then be going on to compose anew from ST's 16-bit saves.

Edit: Ivo beat me to it.

Thanks Ivo, that helps a lot.
I take note of you comment on file size, certainly in the past its a big issue, but nowadays disc space is cheap etc.
Its not so much of an issue.
My sort of point is that , with the fantastic new hdr, deconv etc, processing can take a long time, and occasionally there are mishaps that end up with
A crashed system, and I would find it very useful to store a copy half way through, even in a temp type of file if not in a ‘normal’ format.
This could then be re loaded after a crash , or at another time, and processing continued.
Just a thought.
Anyway , thanks again for the reply, and of course for continually improving this great product!

Hi Ivo,
I do support Andy's idea. Possible storing states would be:
1) After final global Stretch
2) After local Dynamik range optimization (Contrast, HDR, Sharp, Decon)
3) After Color
4) After Denoise

The file would contain image and TRK info, So this could be relaunched

Cheers,
jochen

I guess I misinterpreted the initial post. I thought it was about the "state," depth, and utility of the file created by using save at some point(s) mid-process. Which I am still interested in, actually, as more complicated workflows employ that saved file (channel combinations in compose, for example).

Instead it was another post about saving so that you can continue from where you left off.

But as to that, if tracking files were to be redeployed, something would probably need to be done regarding ST's working folder, perhaps the creation of a new folder to hold those trk files, along with some extra file(s) if needed to help reconstitute the state upon a "load."

We'd (meaning of course, Ivo lol) also need to make sure that there still is a save-as for image output, with the save state being a new feature.

Due to ST's time-shifting nature, it seems to me a save state could be done almost anywhere within tracking, Jochen. Possibly fairly readily if it's only one dataset that it can be done for. Once one gets into saved states for different datasets, or the same dataset but at different points, then things might get dicey.

Even Gimp, which can write out a huge "save state" project file, does not include the operation history in its saves.

I would also worry about the integrity of the startools log file when it comes to saved states, so that's something that would need massaging too.

It's interesting, but I don't know how useful save state really is. That said, my beginner usage may be less complicated than the workflows others are doing, where perhaps it would be very handy.

... I think its main use would be after crashes. ST processing is fairly quick, even on my old imac, so I think Ivo will sort it on his priority list somewhere between ST 12 and ST14
By then even Alder Lake and M1 CPUs will be dinosaurs so I don't see any hardware limit in that.

Mike, You are right, the image could be saved in any state within tracking but it might seem more simple on paper than it actually is in reality. This is why I suggested certain states ( equivalent to the Restore logic ). As a prerequisite a user would need an indication of modules used already before (green letters/ button borders etc.). Some such would be helpful for general use as well.

cheers,
jochen

I find STReplay an excellent tool to help recreate what I had done up to a crash or when repeating 75% of a workflow but with new tweaks.

.... unfortunately st replay is Windows only
cheers,
jochen