UPDATE FROM MABULA
I have had a very rough 2 months unfortunately health wise. I was struck 3x in a row with bacterial infections. The second infection occurred after a routine hospital checkup and I became very sick. I had to rest and take a lot of antibiotics. Once I was recovering and restarting work 1 month ago, I again became sick. The infection was not yet gone, so even more antibiotics and rest was needed. Needless to say, it took a lot of my energy and I needed a lot of rest.
Finally, the infection is really gone and my energy is coming back step-by-step now and I have started work again. I am terribly sorry to have kept you waiting for support. I will address all outstanding questions and e-mails step-by step and will be on the forum daily from today.
APP 2.0.0-beta47 will come soon as well, a lot of work was already completed before I became very ill, so the release is also nearly ready for you. Beta47 will be much faster actually. Many workflows will be more than 2x faster, mosaics can even be 10x faster than before because registration really received a major boost... all compared to beta46. Before I release it, I will make sure that everything is working properly and then I will release it.
Hi Mabula, for particularly bright DSOs I would sometimes like to be able to combine multiple integrations from different ISO settings or, more commonly, exposure times in a HDR-like manner later in further PP software. In order to do this most HDR combinations require the files to be combined (here the results from different integrations) to be separated by regular EV values between each image (often 1EV). Thus in APP if I have multiple integration results from say 30x4s, 30x8s, 30x16s, 30x32s, 30x64s, 30x128s subs - I would want each separate integration to be stretched by the same amount (rather than what may be optimal for each integration) and thus maintain the 1EV difference between each integration result. (Of course each integration would require appropriate darks etc). The classic case for this would be data from M42 for example, with, in the above example, the 120s integration typically having a blown out central core, and the 4s integration only showing the very bright center ...
Thus my question: How can I ensure the same absolute stretch is applied to different integration results?
Related to this is, I guess, the question, is the St slider linear? i.e. if i double the value in the St slider do I half the stretch?
Many thanks for your help, and sorry if this has been asked elsewhere ...
All the best,
Mark
(NB, my understanding is that such a "true HDR combination" is not directly possible in APP)
Hi Mark @mark-james-ford,
Thank you very much for your technical question.
Ideally APP would be able to make a HDR composite using the linear integrations, but I have not yet implemented HDR processing in the RGB Combine tool...
Now to be able to make an HDR composite like you indicate with other PP software, I would recommend the following:
It is vital to normalize all those stacks first, in that way the background of the images will be compatible. So load all integrations as lights and process up until 5)normalize where the integration are aligned and normalized. Save them with the option in 5)normalize.
Those normalized stacks can now use the exact same stretch. So load the normalized stacks into APP. Disable the auto-stretching of APP. And then try to find a stretch setting that works nicely for all the stacks, so for the 4s stack you want it to show the core nicely, and for the 128s stack you want it to show to faint outer parts still if possible.
Save all those stacks with the save button below the histogram with the strecht that you chose and then import those stretched stacks into your PP software of choice to make the HDR.
Now to further eleborate on this, the st slider definitely is not linear, and all stretching algortihms makes the data non-linear and work in this way. So I would be very surprised if you actually maintain 1EV difference when comparing the the stretched stacks visually after any identical stretch on all those stacks. But this is probably too technical and not of real concern here 😉
Please let me know if this helps 😉
Mabula
Hi Mabula,
Thank you very much it definitely does. 😀 Certainly, I will follow the suggested workflow as you describe at the next opportunity! 👍 I fully appreciate the stretch itself is non linear and results in, of course, a non linear image. I simply wanted to know how to add approximately the same absolute stretch to the different data-sets and your answer gives me that opportunity. In absolute terms you are right, the net results are not identical to a simple 1EV difference but the absolute difference between the final stretches should be (and that is my hope), at least to a first approximation, when not necessarily mathematically justifiable 😉, proportional to a particular +/- EV value and that should be sufficient. The HDR rendition being in any event a somewhat "artificial" reworking of the data.
Btw: In the past i tried from just two data sets (1x long exposure, 1 x short) to eyeball various stretch settings, generating 3-4 final images from each data set with different amounts of stretch, and "pigeonhole" them into various +/-EV values in the HDR software - it kind of worked but the results didn't really deliver what I know should be possible ...
Thanks again, Mark
