AutoStretch button in ScreenTransferFunction dialog

[Yuriy Toropin]

Hi PI team!
What do you think, may be it makes sense to redesign ScreenTransferFunction dialog a little bit so that one press on "Lamp" (Auto Stretch) icon-button will lead to immediate action (aplication of pre-configured "curve" and image stretch on screen)  instead of bringing up setup dialog first that usually is used just for pressing OK button?
Especially in active Track View mode?

Setup for predefined parameters of Auto Stretch should be called by some other icon-button.

IMHO, I really like that Auto Stretch, in majprity of cases I don't care about changing it's parameters and default ones work quite well. If I will need to correct ScreenTransferFunction after application of Auto Stretch I will use sliders on main dialog, not will be played with sliders or numbers in STF Auto Stretch dialog or - will change default Auto Stretch parameters. Once for a while.

Thanks,
    Yuriy

PS: Guys, there was another suggestion to provide option to show stretched "negative", "inverted" images through AutoStretch. Even it was promised for 1.5.6 I think...

[Juan Conejero]

Setup for predefined parameters of Auto Stretch should be called by some other icon-button.

Good suggestion. This can also be implemented by Ctrl-Clicking the lamp button (because the STF interface is already well populated). Thanks! I'll try to include this for 1.5.8.

PS: Guys, there was another suggestion to provide option to show stretched "negative", "inverted" images through AutoStretch. Even it was promised for 1.5.6 I think... Huh?

And it was implemented in 1.5.6 The STF Auto Stretch function detects an inverted image (easy: the main histogram peak is above 0.5) and automatically subtracts the selected target background from one. The shadows clipping value is subtracted instead of added, so the meaning of its sign is also inverted. Just try with an inverted image. You think in terms of non-inverted, and STF does the correct thing. This is the intent, at least.

However, I must say that there seems to be something wrong because the automatic inverted stretch fails sometimes. I'll investigate to fix it in 1.5.8.

Thank you!

[Yuriy Toropin]

PS: Guys, there was another suggestion to provide option to show stretched "negative", "inverted" images through AutoStretch. Even it was promised for 1.5.6 I think... Huh?

And it was implemented in 1.5.6 The STF Auto Stretch function detects an inverted image (easy: the main histogram peak is above 0.5) and automatically subtracts the selected target background from one. The shadows clipping value is subtracted instead of added, so the meaning of its sign is also inverted. Just try with an inverted image. You think in terms of non-inverted, and STF does the correct thing. This is the intent, at least.

Cool! 
Then - it was implemented not in a way I thought it should be implemented.  8)

In initial post some time ago, before 1.5.6 I asked about showing normal image in negative, inverted way via STF just for preview and investigation purpose.

...

Nonetheless, I think you suppose that image, if needed, should be inverted first and then shown correctly via STF in its (real now) inverted state.
I don't totally like this approach 'cause it means real change of the image instead of just representation of normal image in special "inverted" way...

[Niall Saunders]

Hi all,

I used this clever feature for the first time last night - this is a classic example of 'information overload'. Juan has been implementing new features so fast that it is hard to keep up with him. We read about his latest new delights - usually at work (sorry Boss ) - and then start playing with them as soon as we get the new code downloaded and installed.

However, by then we have only remembered HALF of the original delights, and the new ones have been so captivating that there is absolutely NO CHANCE of ever going back to his detailed Forum message to see what we don't even know we are missing out on !

That said, the point I wanted to make was that, last night, I was playing with different methods of the ImageIntegration process - on different images created by my CMYG Batch deBayer script - all from the same source data (fully calibrated within PI itself). I therefore had TWENTY-FOUR 'identical' images on screen, all with a different method of creation, and I wanted to use the 'Magic Light Bulb' on all of them.

I already had an ImageContainer for the 24 images (what a useful tool THAT is), but I couldn't apply the MagicLightBulb to the ImageContainer. Not an insurmountable problem - it justy took a little bit of time and patience - I had already spent hours patiently creating these twenty-four images anyway, so a few more minutes wasn't going to matter.

It is just that you posting here made me wonder whether 'my' requirement had a simple solution. In other words, could an automatic STF be applied to all images in an ImageContainer? (And, if so, how?)

Cheers,

[Carlos Milovic]

Hi Niall, there is an option to copy the current STF to all views

[Yuriy Toropin]

Returning to the subject -
please, please, give me the "Inverted| icon-button in STF, better - in parallel to immediate Auto Stretch! 

[Niall Saunders]

Hi Niall, there is an option to copy the current STF to all views

Hi Carlos,

Yes - but how does this process know that it has to recalculate the slider positions for each target image to which the STF will be applied?

If I click the Light Bulb, PI establishes a set of slider positions for the <target> image (as I remember, I'm not in front of PI at the moment). Surely if I then apply the STF <globally>, all that will happen is that the slider positions calculated for the first target image will just then be applied to all other images (the problem that I perceived to be the case with the ImageContainer).

Am I missing something (and, sorry to be hijacking your thread, Yuriy)?

Cheers,

[Carlos Milovic]

You are right, the same STF is copied, not recalculed by the stats. I thing that a separate process should be implemented for this (AutoSTF, like the AutoHistogram process).

[Niall Saunders]

You are right, the same STF is copied, not recalculed by the stats. I thing that a separate process should be implemented for this (AutoSTF, like the AutoHistogram process).

Good idea, Carlos.

Of course - this would be an ideal candidate for a PJSR script - that really is exactly what the scripting process should be used for (to allow Juan to complete more important tasks, only needing to re-evaluate the situation if a PJSR script shows enough merit to be considered for inclusion into the 'core' of PI).

Any takers? 

[Carlos Milovic]

I can do the process module, this is not big deal. After all, I wrote AutoHistograms I'll just need to vampire the algorithm Juan is using to calculate the mtf, 'cause I used a gamma transform (much easier to predict the final median value).