UI suggestions: add 'undo' to all process dialogs, more

[Nocturnal]

Hi,

I think it would be great if either all process dialogs had a preview function like the histogram or if the 'undo' button is right on the dialog. I realize the undo is available under the Image menu but to new users it may seem strange that radical operations like SCNR don't have a preview or undo right there.

Why doesn't PCL use standard buttons for Apply Cancel and OK? The style is called 'XP' but frankly it doesn't look anything like XP. I saw this mentioned in another thread as well and I agree that for complex software like PCL everyone benefits from using standard GUIs. There is no need to re-invent the wheel. It's been invented :-) The small icons on the bottom are efficient and there's nothing wrong with them except that they are not standard. At least not on Windows. I admit I haven't used many Unix GUIs since my Solaris days 14 years ago but even those had text buttons. I don't know how modern Linux GUIs operate but they probably emulate Windows behavior as much as possible so that the transition is easier.

To be clear, I love PCL and the price is right so I'm not complaining, just offering my suggestions for improvements that I think will help the adoption rate of your product.

Thanks for your consideration,

  Sander

[Juan Conejero]

Hi Sander,

Oh yes, indeed we are inventing many GUI concepts for image processing applications.

PixInsight doesn't have a document-oriented graphical interface like most imaging applications. This is what you have detected as a nonstandard behavior. Ok, this feeling is just the first step; once you understand the PixInsight way, you'll be caught definitely; don't say I didn't tell you

Excuse me for this long answer to your post, but you've touched some key points that relate to extremely important topics about our software, so some detailed explanations are necessary.

Let me explain some key points about PixInsight's architecture and GUI design. In a traditional document-oriented interface, you basically perform the following actions:

1. Open an image, or select an image that is already open.

2. Go to the main menu and select a command, or use the corresponding accelerator key.

3. A dialog box opens. Normally, this dialog is modal. This means that you cannot interact with the rest of the application until you accept or cancel the action that the modal dialog is intended for. Perhaps you can interact minimally with the image, for example by clicking on it to gather some data that the dialog uses, but this interaction is strongly limited by the dialog's own functionality.

4. If you agree with the dialog's settings, you click the OK button, or press Enter, and the command executes. Or you can click Cancel (or press Escape) and then nothing happens.

5. Go to step 1 or step 2, or exit the application.

What's wrong with this scheme? Nothing at all, except it is sooo boring... :lol:

Jokes apart, what I've depicted above is just the conventional document-oriented interface paradigm. It works, of course, and in fact most applications follow it today. However, PixInsight is completely different.

The PixInsight platform does not use a document-oriented GUI paradigm at all. Instead, we have implemented an object-oriented graphical user interface. Let me explain the difference. In a document-oriented interface, processes (e.g. menu actions) and objects (e.g. images) are mutually dependent. This means that without an image, you can't perform a process. In other words, a process isn't an independent element and can't live without an image to be applied to. Note that the document-oriented design has extremely important implications beyond the GUI face: it is an architectural paradigm that affects the structure of the application as a whole.

The object-oriented paradigm that we have designed and implemented in PixInsight is founded on the opposite concept: processes are self-contained, self-sufficient, independent objects that exist and live without images. For example, you can open the PixInsight core application, launch the CurvesTransform interface (double click its icon on the Process Explorer, TransferCurves category, or select from Process > TransferCurves > CurvesTransform), and define a set of curves. Then you can drag the New Instance button (triangular, blue) to the workspace to generate a new process icon. This icon encapsulates a CurvesTransform instance that you can save for later use. Note that you still haven't opened any image. This shows you a tiny fraction of PixInsight's object-oriented strength.

So now you know why there are no OK and Cancel buttons on processing interfaces like CurvesTransform, SCNR, etc. Simply put, there is nothing to say OK or Cancel to on a processing interface in PixInsight. Sometimes I like to summarize the differences between our object-oriented design and the traditional document-oriented design in this way: PixInsight's object-oriented architecture is like a tree, while others' document-oriented design is just a line. A tree where the root is the PixInsight core, where we have at least three branches (namely the graphical interface, the command-line interface, and the scripting interface), and where leaves and fruits are processes and images. Compare this with the line between your image and the OK/Cancel dialog in other applications...

There is much more to say and explain about this topic (how different processes can interact, how processes are fully reusable in PixInsight, how the three interfaces work cooperatively, etc), but this looks like enough lengthy as a brief explanation... :lol:

I think it would be great if either all process dialogs had a preview function like the histogram or if the 'undo' button is right on the dialog. I realize the undo is available under the Image menu but to new users it may seem strange that radical operations like SCNR don't have a preview or undo right there.

Unfortunately, not all processes can perform real-time previews like HistogramTransform, CurvesTransform, etc. The main problem is that many processes are too complex and too processor-intensive to provide a useful real-time preview. For example, having to wait for more than 3 - 5 seconds for a real-time preview isn't actually too "real-time"... With multicore systems becoming standard, we'll be implementing real-time previews for more processes in the short/middle term.

In other cases, a real-time preview can be implemented, but we haven't done it yet (because of our priority schedule). A good example is SCNR. In general, real-time previews are not critical in these cases (or so I hope).

Besides real-time previews, PixInsight implements an extremely powerful mechanism to try out processes without modifying images: preview objects. You can define any number of previews over an image. Open an image and select the New Preview mode from the control bar, or press Alt+N. The cursor shape changes to a small paper sheet over the image. Now click and drag to define a rectangular area. Use the Edit Preview mode, if necessary, to adjust the rectangle's size and position.

When you create a preview, note the small vertical tab that appears at the left edge of the window. This is the preview selector. You can click it to select the preview image. Now you can work with the preview as if it were a normal image. However, the preview is just a temporary subimage that you can change without altering its mother image at all. For example, click an Apply button (square, blue) on a processing interface with the preview image selected, or drag a process icon, or a New Instance button, to the preview.

You can undo and redo a preview just like a normal image: press Shift+Ctrl+Z to undo/redo. However, unlike normal images, when you apply a new process to a preview, it is restored from its last unmodified state first. This means that you can apply successive processes to a preview without needing to undo it. There are other options that allow you to accumulate processes on a preview, as Preview > Store, but this is more complex.

Why preview objects instead of only live previews, as do most imaging applications? There are three answers:

- Because other applications apply only simple procedures that allow live previews very easily, while PixInsight implements very complex and numerically intensive algorithms. Go imagine how the ATrousWaveletTransform process, to put a moderately complex example, could make a live preview...

- Because we have a sophisticated real-time preview interface, which is much more versatile and accurate than live previews are in other applications.

- Actually, the most important reason: preview objects are accurate and modular. Since a preview is a subimage with the same bit depth and data type as its mother image, and it contains exact copies of mother pixels, it gives you the possibility to evaluate what a process will do when you apply it to the whole image. Furthermore, you can reuse a preview's processing history to apply it to other previews, to other images, or to store it as a disk file for later use. Or you can convert a preview into an independent image... and lots of useful things that make preview objects some of the most versatile elements of PixInsight's architecture.

I don't know how modern Linux GUIs operate but they probably emulate Windows behavior as much as possible so that the transition is easier.

Well, better don't talk about who emulates who... Funny things apart, PixInsight is rebel in many aspects. With its innovative design, there are many things in PixInsight that are necessarily "strange" on any platform, either Windows, Linux, or Mac OS X. We know this and are conscious that some nonstandard characteristics of our interface may seem intimidating to new users, but this is our raison d'être

PixInsight builds on top of Qt, which is by far the most powerful and flexible application development framework (it's in the core of the KDE desktop environment, for example).

Now to be completely sincere, we don't like Windows too much. It's no secret at all I strongly recommend you to try PixInsight on a modern Linux distribution (Ubuntu, Fedora, SuSE, Mandriva). It's much more reliable, faster, and makes much better use of the available memory.

Thank you for raising so interesting topics.

[David Serrano]

Thank you for that really brief introduction to PixInsight design concepts. I want to seize the opportunity to ask about a set of processes that, for some reason, are different from the rest: dynamic processes.

I think the best of the questions is, why did the need of a dynamic process arise? (I'm assuming an actual need for them). My wild guess is that, at some point in the past, you realized that something couldn't be achieved using a regular process, so you came up with this workaround. I see them as stains in the program, things that prevent the OO architecture from being entirely consistent.

Or maybe they are just a convenience tool: being able to crop an image by interacting directly with it (DynamicCrop) or moving DBE's samples with just a mouse drag are things that would be very frustrating if they were to be done via text boxes and sliders only.

An actually brief note on this is enough for me.

However, unlike normal images, when you apply a new process to a preview, it is restored from its last unmodified state first. This means that you can apply successive processes to a preview without needing to undo it.

I'd like to encourage you to stress this point in the final documentation, since I think this difference between previews and images can make people go nuts if it isn't clear. Stressing the possibility of undoing-redoing with the same keystroke (or interface button) wouldn't do any harm either.

I have more suggestions, but I think it's best to make them in separate posts.

[Juan Conejero]

why did the need of a dynamic process arise? (I'm assuming an actual need for them).

Actually, there are no dynamic processes in PixInsight Surprised? There are only dynamic interfaces. However, we loosely talk about "dynamic processes" as a shortcut to those processes that have one or more interfaces that can operate in dynamic mode.

It's easy to verify a practical consequence of this. For example, nothing prevents you from writing a script to define and execute an instance of DynamicCrop:

Code: [Select]

//
// Define an instance of the DynamicCrop process to perform a crop centered at
// the geometric center of the target image, rotated 45 degrees counter
// clockwise, and filling unused regions with solid orange color.
//
var p = new DynamicCrop;
with ( p )
{
   centerX = 0.5;
   centerY = 0.5;
   width = 0.75;
   height = 0.75;
   angle = Math.rad( 45.0000 ); // 45 degrees in radians
   scaleX = 1.00000;
   scaleY = 1.00000;
   optimizeFast = true;
   interpolation = Bicubic;
   blockSize = 5;
   red = 1.000000;   // fill unused areas with orange color
   green = 0.500000;
   blue = 0.000000;
}

//
// Now execute it on the active image window.
//
p.executeOn( ImageWindow.activeWindow.mainView );

You could do the same with DynamicBackgroundExtraction, DynamicAlign, etc. In fact, you can instantiate and execute any process (with the only exception of Script) from a script. This demonstrates that, from a purely functional point of view, there are no differences between processes, regardless of the fact that they have dynamic interfaces or not.

My wild guess is that, at some point in the past, you realized that something couldn't be achieved using a regular process, so you came up with this workaround.

Not at all. As I've stated above, there are no dynamic processes. All process classes in the PCL have two execution member functions (inherited from the Process PCL class):

virtual bool ExecuteOn( View& );
virtual bool ExecuteGlobal();

The first member function must be redefined by a process to implement execution on views (images). The second one is reimplemented by processes that can be executed in the global context (not on any specific image). That's all for every process in PixInsight. So as you can see, there's nothing about dynamic bahavior in a process.

Dynamic interfaces actually arose in early stages of the general platform design. There is an obvious need for interfaces that allow users to interact with images dynamically. Two well-known examples are DynamicCrop, as you have said, and DynamicBackgroundExtraction. Without the possibility to define dynamic interfaces, the PixInsight platform would be severely limited.

Actually, the PCL provides an immense power and flexibility to define dynamic interfaces that we have not seriously exploited yet. For example, the PCL allows for generation of extremely sophisticated graphics, both vector-based and bitmap-based, and an interface can perform as both dynamic and static. DynamicCrop is perhaps the most elaborated dynamic interface currently available, but much more refined things can be done. Be prepared to see a dynamic revolution in PixInsight during the next months