Repaired HSV Separation Script

Bob Andersson

Well-known member
Hi folks,

This script owes its genesis to a discussion on "true colours" and the way that the H, and to a lesser extent, the Sv separations of an HSV channel separation clearly show the effects of non-linearity in the underlying data. The script allows one to set a threshold above which data is assumed to be non-linear and attempts to draw colour information in from the surrounding pixels. It also attempts to restore a more peaked profile to the luminance information but that processing is fairly conservative and an option exists to output an "unrepaired" version. The script may be downloaded from here, it was developed and tested under PI 1.7 and the interface looks like this:

REpHSVDialogBob.jpg


The intention is to apply the script to linear data. Using this (6.8 MB FIT) test crop here is a screen grab of the unstretched image which illustrates a problem:

TestCrop_With_Loupe.jpg


There is no reason at all to suppose that the star actually changes colour as the core is approached, quite the opposite in fact. After running the Repaired HSV Separation Script the result looks like this:

TestCrop_Repaired_RGB_With_Loupe.jpg


It looks weird but the relative ratios of red/green/blue at the center of the star highlighted by the loupe are now pretty much just as they are away from the star's core. While I've offered the option of outputting a "repaired" but unstretched RGB the purpose of the script is primarily to output repaired H, Sv and V separations so that the V separation can be stretched before recombination with the H and Sv data. This offers a way to stretch an image without the usual loss of colour saturation. Here is the result of passing the V image through the MaskedStretch script (100 iterations, Target Median 0.15), recombining with the H and Sv images and doing a spot of clipping and colour balancing:

TestCrop_V_Stretched.jpg


Quite an extreme look and not one that will win many prizes. The script can highlight chroma noise quite readily if the underlying data is poor. For comparison here's how the same MaskedStretch settings changed the "repaired" RGB:

TestCrop_Repaired_RGB_MaskedStretch.jpg


And, for fun, here's what the two images look like when added together in equal proportions using PixelMath:

TestCrop_Both_Stretches_Combined.jpg


Comments and suggestions are welcome. This is my first attempt at JavaScript, and that probably shows, and my first spot of programming in over ten years having previously dabbled as a self-taught C++ programmer so please forgive the multiple stylistic errors.  :)

Bob.
 
Hi Juan,

I'd be honoured. Do you think it might be worth waiting a short while to see if any bugs surface or if improvements to the algorithms are suggested?

Bob.
 
Thanks Bob. Nice idea!

I have however found a couple of errors using it in PI v1.8RC3:
  • Selecting the option "Repaired RGB" doesn't seem to do anything.
  • It fails at the line 264. The version 1.8 seems to have an stricter validation of the parameters of ImageWindow(). It should be:
Code:
let inputWindowCopy = new ImageWindow (1, 1, img.numberOfChannels, img.bitsPerSample, img.sampleType == SampleType_Real, img.isColor, inputWindowCopyName);
 
Hi Andres,

Thanks for the bug report - having feedback from the PI 1.8 release candidate is particularly useful as I've still not dipped my toe in those waters yet. I've duly amended the code as you suggested and uploaded v1.0.1 (same download location here).

I did notice that a similar "new ImageWindow()" constructor was in place to create the "Repaired RGB" window so I've also amended that as well. Hopefully that will solve your other issue.

Bob.
 
Hi Bob,

both bugs in 1.8 are resolved but there is now another one  ;)
In the line 42 you have to use quotes in the version number because otherwise it fails at the line 727.
 
Hi Andres,

Darn it - you got there just before me! I needed, as you so rightly pointed out, to enclose the version number in quotes - fixed and thanks for your help. I added your name to the change log.  :)

Bob.
 
Hi Andres,

I'm more than happy to leave your name there (maybe I should have asked) but if you want me to remove it then say the word.

Bob.
 
Hi folks,

I decided to remove my Pleiades image from this thread (too blue!) and replace it with M42. As noted below I really struggled with the weather this winter but I hope the result, even with such a limited number of subs, demonstrates that the script doesn't just have application to the stars.


M42_1024x1024.jpg


    M42 - The Orion Nebula

5 x 40 seconds in each of red, green and blue and 6 x 200 seconds in each of red, green and blue. I managed just 6 x 1,000 seconds of red subs and 2 x 1,000 seconds of blue subs and without any green that wasn't a lot of use for this object. And narrowband never happened - what a winter! Captured via my TEC 140 (f/7) and my FLI ML16803. The 100% version is available here for pixel-peeping fun.

Bob.
 
Hi Bob, thank you for this script!, and nice image (I liked the pleyades too).

I start playing a little with it and discover something that could be a bug.
Screenshot 1: All works fine over the full image
Screenshot 2: in a small image generated from a preview the "Repair Level" parameters is allways 1
If you increase a little the size of preview it is enought to it work fine again.

Saludos. Alejandro.
 

Attachments

  • Repaired HSV1.jpg
    Repaired HSV1.jpg
    211.2 KB · Views: 160
  • Repaired HSV2.jpg
    Repaired HSV2.jpg
    232.1 KB · Views: 153
Hi Alejandro,

I tried reproducing the behaviour using my M13 data but without success. It would seem that the pixel intensity of the histogram's peak as reported by the HistogramTransoformation module (my script, line 1188 of version 1.0.1) is 65536 (I'm using the module in 16 bit mode - line 1175). In the normalised range of 0.0 to 1.0 that equals 1.0 which is strange. I've never tried using the script on an image which hasn't been rescaled but which does need rescaling - is there any chance at all that the original image does need rescaling? That wouldn't be a problem when the script is looking at the whole image because most of it is dark so peaklevel would be well below the limit but when dealing with a crop of the bright central area maybe the peaklevel is off the scale?

Bob.
 
Hi Bob, you are right, it does not depends on the size of the preview, but where it is located.
Besides I tryed to reproduce it in other images without succes.
I have uploaded to endor the image where it can be reproduced. It is in Forum Shared Files > Alejandro Tombolini > "HDR_Cumulo_Test_RepairedHSVSeaparationScript.fit"
Direct link
Saludos. Alejandro
 
It is not a surprise.
Do you have an Endor account to download it directly? It is hosted in Forum Shared Files > Alejandro Tombolini > "HDR_Cumulo_Test_RepairedHSVSeaparationScript.fit"

If you do not have an account, please send a request as descibed by Juan:

Juan Conejero said:
To use PixInsight Files you must be a registered user of this new service. If you want to register, please send us a request at any of our support email addresses, or use the contact form on our website. To help us identify you, either use the same email address that you have associated with your license, and/or specify your user id. You can find your user id (a 16-digit number) in the email you received when you purchased your license, and also on the Resources > About PixInsight dialog of the PixInsight Core application. Unless you tell us otherwise, your PixInsight Files account will have the same user name and password as your current PixInsight user account (which you use to access our Software Distribution interface).

Hope you can download it.
I'm more interested in the script as I begin to understand the improvements that can be achieved in the stars! :)

Saludos. Alejandro.
 
Hi Alejandro,

I downloaded your image file this morning and I was quite surprised to find that you are applying my script to an already stretched image. Not the intention but I guess there's no reason why not.

I also reproduced the behaviour you described with a central crop derived from a Preview. I've tweaked the relevant code and released version 1.0.2 which should solve your problem - see my next post for the link. Let me know how it works out. Thanks for the report.  :D

Bob.
 
Hi folks,

I've now released v 1.0.2. This is a minor bug fix with no change to the script's basic functionality. The displayed precision of the clipping and repair level sliders has been increased and the way the maximum clipping and minimum repair values of those sliders is calculated has been improved.

The original download link (first post) holds the latest version but to save you from going looking you can find the script here.

Bob.
 
Hi folks,

I've been reworking some old data of the Soul Nebula and got a bit of a shock: so many colours in the stars! I used the Repaired HSV Separation Script on the RGB (made from 5 x 200 second subs in each of red, green and blue) to produce both repaired HSV separations and a recombined (repaired) RGB and then used the Masked Stretch script on both the V separation and the repaired RGB. The H, Sv and (stretched) V were then recombined. As usual that produced a strongly coloured image but as the colour is pretty uniform across the stars they looked a little flat. By contrast the masked stretch of the "repaired RGB" had reasonably good colour but that colour still washed out in the brighter stars. So, for purely aesthetic reasons, I added one third of that stretched repaired RGB to the recombined (stretched) HSV image using PixelMath with the "rescale" option turned on.

Sounds complicated but here's what it can do. First a 100% crop from near the top left of my 4096x4096 pixel image:

Soul_Crop_Red_Chain.jpg


I'll 'fess up and admit that some of the brightest stars still needed a little manual cleanup but I hope you'll agree that the extra work is worth it. Just an otherwise nondescript patch of sky but so beautiful when the star colour is retained.

And then there's this:

Soul_Crop_Inc_Blue_Object_Arrowed.jpg


For orientation north is up and you can just see IC 1871 making an appearance in the top right of the frame. Pretty enough but there's something star-like, faint and very blue (highlighted). As near as I can judge it is at 02h 58m 50s, +60? 37' 22" but that was working from TheSkyX and purely by eye so the position probably isn't that precise. It doesn't appear to be noise but I can't identify it. The RGB subs were all captured on the evening of September 18th last year so whatever it is or was is now old news but I never spotted it when I originally processed the data because at that time I still hadn't discovered how to retain the star colours during a stretch.

For reference the whole frame can be seen here, reduced in scale by a factor of four. This has some decidedly experimental processing of the Ha data (8 x 1500 seconds) as I was trying to enhance the fine detail while still controlling the Ha intensity so as to allow those star colours to shine through.

Update: I found out what the anomalous blue object is! I was a bit off with my coordinates as it sits at 02 57 45.41, +60 34 25.2 and goes by the name of 2MASS J02574541+6034251 or Lan 272. It is shown here on the Simbad portal. It is one of the "UV bright" white dwarf's listed in Lanning's catalog. There is a paper (PDF link) which includes a spectrum of Lan 272 and shows just why it appears so blue in my image and if I'm reading Table 2 of that article correctly Lan 272 has an effective surface temperature of 90,410? K. :eek:  I think I'll claim this as a win for the workflow described in this thread as I'm pretty sure I wouldn't have spotted it with a more conventional stretch.  :)

Bob.
 
Back
Top