Hi Gustavo,
Thanks for writing this thoughtful post.
gustavo_sanchez wrote:Hello,
I have been a regular user of StarTools for some time now. Each time, I have seen it grow successfully, adding functionality to necessary tasks. However, in the most recent updates, I have seen so many changes, such the latest changes to the De-noise module and the Color module, that are "bloating" the software a bit. Like, there is the "true" StarTools color visualization option, and the "other software" visualization option. The initial question went from "data is linear or not?" to "data is linear, or de-bayered, or color-balanced, or stretched, etc?" By the way, can we de-bayer the image in StarTools?
I know change is something that is strenuous to deal with as it's something that demands our attention, rather than being optional. However I must vehemently disagree that the latest changes are causing bloat in the software. As a matter of fact, the opposite is the case. The total parameter count has remained the same or has gone down in many modules from where it was a year ago (denoise being an exception), while operation of many modules is now much more targeted, automated, consistent and/or more powerful.
The color module has gone through some very important changes that have made its operation much more robust, predicatable and streamlined, while now yielding better results than other color calibration tools.
This
brand new tutorial highlights how easy it now is to process LRGB data sets, without having to process luminance and color separately (like you do in other applications and older versions of Startools as well). The color module now suggests (what it thinks are) appropriate multipliers for red, green and blue automatically and because the Color module now uses Tracking information we have been able to dispense with the gamma correct sliders from ST 1.0/ 1.1 / 1.2. All this has been accomplished without adding to the UI. Ergo, the way the new color module now completely separates color from luminance has effectively cut down the amount of work you do for an LRGB data set in half, without adding more parameters, while making the results look better. I can't see the bloat in that.
Having freed up some parameters, the unique way StarTools (Tracking) works has allowed me to start helping users achieve certain looks much easier at the click of a button - with a simple dropdown menu you can make your colors look like they were the result of an LRGB composite (even if it's just DSLR data) with Rob Gendler's method of compositing. Or if you prefer, you can select Till Credner & Paul Kanevsky's LRGB ratio method of color preservation, etc., all with their subtle impact on hue and saturation in your image. What otherwise is the result of many complex operations, and would have othwerwise have required many options and fiddling with pixel math is distilled down into a single selector. To me that's the opposite of bloat.
Going even further, the new color module finally gives a name (and well defined behavior) to how StarTools 1.3.2+ has been rendering its colors. Tracking has allowed StarTools to keep track of any hue or saturation shifts, which under the 'Color Constancy' regime allows for true color object rendering across the full image. No longer does the brightness of an object, nor how much you stretched the image have any bearing on how its color is represented, allowing the viewer of your image to objectively compare features, star temperatures and chemical composition across the image; M31's core is not white, it's yellow (older stars). Brighter stars don't magically chnage color temperature just because they're birghter. M42's core is green (OIII dominant) not white, just like the less bright nebulosity next to it. Globular clusters don't have white stars at their core, they are the same type of stars. Color constancy fixes these things with a parameter, which is one by default. If you prefer the old (incorrect way) of rendering color as found in many PS and PI workflow tutorials, then you can mimick this look using that parameter.
I can't see how giving the user this much additional power, control and reduction in processing steps (in the case of LRGB sets), with the same amount of parameters as found in 1.1 / 1.2, can constitute bloat!
The Intial question (is data linear, not linear, etc.) is still only one question. There are no additional dialogs and once you know which answer is best for your data, it's no additional work or bother. Meanwhile DSLR users get a small noise reduction bonus. Again, it's the opposite of bloat - you get more quality/functionality with the same amount of clicks or parameters.
Meanwhile, we are only getting one undo option. I think that is there is one, there could be more. There should be a better way of retracing our steps so we can fix processing mistakes we made several steps before. I tried to re-develop my image from scratch after I used deconvolution, color, contrast, life, and sharpening modules, and the re-stretched image was not close at all to what I had before, even using the exact same develop settings. It would be nice to have a way where we could keep track of what we have done, and if we want to change something, then simply go back and change it, either object-based or a list of processings.
This sound like a bug, but I'll have a look. Meanwhile, have you tried the new 1.3.5 'Restore' button option? It allows you to quickly restore the state of the image to as it would be with a number of combinations of core algorithms applied. As you hopefully know by now, StarTools does not process its images in a linear fashion but goes back and forth in time to apply algorithms at the best possible moment, allowing for redoing and undoing of 'aspects' of the image. That's how it gets better results in less time, while allowing for some pretty unconventional things like decon of stretched data and color calibration at the end of your processing (rather than the beginning). Undoing in a linear fashion would require not just keeping track of the last step performed, but keeping track of its full array of tracking data. It can be done, but the drive space required, as well as the olny marginal benefits outweigh the pros at the moment.
Well in conclusion, I think that Startools from like four months ago was more intuitive, even with less features. Now it has been getting harder to keep track of the changes and adapt my workflow to it. It is forcing me to skip updates to stick with what I know how to use. It would be nice to have some way to better integrate all these changes and make them easier to execute and apply as part of a workflow. Startools now is becoming (at least for me) somewhat complex.
It's not a matter of stopping the innovation, this software is very good. It's just that it is starting to feel like a bit bloated and less integrated with each passing update, at least from my user point of view.
It's unfortunate that you find this being the case, as a lot of development time goes into exactly into integrating tools better, making them easier to operate to greater effect with the same amount of controls, and finding ways to make StarTools more powerful while keeping the UI clean and simple. I think the latest videos reflect the consolidation of a one-stop-shop workflow as well. The datasets vary wildly but all follow roughly the same workflow, with the later videos showing an increasing effectiveness of presets and standard module behavior. The user is always right though, but I think upcoming task for me is more about (re)educating StarTools' users about the newer, quicker and better ways to process their images. Indeed 1.4 will be more about under-the-hood architectural changes than it will be about new features & changes. This will hopefully give people time to come to terms with the changes.
Thanks again for your candid thoughts on this Gustavo. They're much apprreciated and they're certainly food for thought!
Cheers,