I'll be speaking at MWAIC '10

[Carlos Milovic]

You can do that with PixelMath

[mmirot]

And thats great for people how want to type. 

I  have to check the syntax each time I use it. 
I am sure others share my opinion , pixel math is pain in the As**.

With and layers , I can set up a combination of six channels or more (RGB OIII SII HA) in one go.
I can change the the blending in real time,    ie HA 90% Red , Blue 10%    to    HA  RED 95%, Blue 5% .

So bit maps with layers has some real power.  I just want the authors to realize this .
It does not require painting tools.

I am not advocating this method as a feature for PI. Just a method worth fair consideration
Scripts and modules for this and other tasks will be easier and more useful than pixel math. 
They will work just great too. Once we develop them.

I just think we should not be so prejudicial to some of PS methods.  I have noted that some software developers often don't want to be influenced by competitors ideas. Some guys want to copy everything.  I think it often best to have little of both worlds. 

Max


 

[Carlos Milovic]

I was talking about modifying the fourier components, although you can emulate the layers too

Ok, going on your topic. I believe that bitmap layers are a must. They give a lot of freedom, and makes things so easier. Also there are so many applications for this, so at end there is little to argue against them. Processing layers are another story, IMO. It is nice to have a cascade, and see how things change if you go back and modify one of them. This works fine with very simple processes, like histogram transform, curves, etc (i.e. those processes that can build a LUT, and works over integer images, likely in 8 or even 16bits). The problem is when you are facing more complex processes, or floating point samples. You can't do this. Or, you can't do this "live", fast. You have to work pixel by pixel, calculating the result. And that takes time, enough to spoil the real time part. Also, in PI we believe in precision above speed. We want the best results we can find, with numerical (and algorithmical) accuracy. For those reasons, I believe that the current history system, working with process containers is the best solution (perfectible, of course, specially all the stuff related to secondary images like masks). You want to change the histogram transform you applied 3 steps before? Create an icon with the current history, go back to the desired state, apply a new histogram transform, and now apply all the processes after that step, modifying the process container you created with the history. Minimum manual input. (And BTW, I would recommend to carefully inspect if the following processes do work best with their current values, or need a change). So, the bottom line, I think that this is just a matter of what you are used to do, vs learning a new way to do the same thing, achieving at the end the same results (but, IMO, much more flexible).

[mmirot]

I agree.
I am sure Juan will add something eventially since it adds to the pattform's flexibility.
It is certainly more applicatible to certain processes the go to LUT.
It would be nice to see some layer functions in PI. How to and when to work that in.... I leave this Juan and you.

Max

[Nocturnal]

Hi,

I certainly agree that layers and painting are not tied together. In fact they have nothing to do with each other can be used independently. I'd vote for layers before painting. Of course I vote for documentation infrastructure and projects before layers

[Carlos Milovic]

If it were my call, I would postpone layers to the 2.0 release, since that is a huge change to the PI core and the PCL.

[Niall Saunders]

Right now, my feeling that the requirement for 'Layers' is only really needed to meet the desires of those who have spent a lot of time processing in PS. I don't think that PI would provide any significant advantage over what we are already used to if we had layers functionality available.

As Carlos stated, let's say that you have an image that has had a 'layer-cake' of processes applied to it. Just because you can then go back and 'tweak' one of the intermediate processes does NOT mean that the subsequent processes remain valid without their own parameters needing to also be 'tweaked'. OK, so there may be trivial cases where this statement does not apply, and where you COULD tweak a mid-stream process without needing to re-evaluate all subsequent steps, but I reckon that the adjustment could just as easily be made as a 'next step', rather than a 'layer tweak'.

History Explorer is our current 'equivalent' of the PS 'layer-cake' - the difference being that you have FAR GREATER control of the 'layering' process, the only penalty being the lack of pseudo-real-time response seen in the integer bitmap world of PS.

Even without 'layers', many of the processes available in PI are just too computationally intensive to integrate into a 'real-time tweakability' layer-cake preview - and that is true even for multi-processor power machines, with plenty RAM on tap as well. So, users would have to confine themselves to VERY SMALL image sections in order to get a dynamic response from their layer tweak, and such small previews will often NOT capture the feel of how the OVERALL image response might look like.

The lack of Layers in PI simply enforces a paradigm shift in processing methods compared to PS - and so what? Just about everything in PI forces the same shift anyway, so what is the problem? Even if 'Layers' become available in PI (and, if I were Juan, I wouldn't waste ANY TIME WHATSOEVER developing this at this present moment), the PixInsight implementation will NOT be a 'mirror' of that used in PS - simply because the PS implementation is very 'crude', again because it was just NOT designed for the floating-point, high-dynamic range world of astroimages.

So, by all means let's add 'Layers' to the PI 'To Do' list, but if that particular Post-It note happens to fall off Juan's monitor and gets eaten by his dog, I don't think any of us should be overly concerned. As Sander says, there is a far greater requirement for full documentation to be created, long before something trivial like layers.

Cheers,

[mmirot]

Right then... time to move on. 

BTW. 1.6.1 works great so far. Nice work Juan.

Max