Proposal to add support for output of alternative versions of input files

XnConvert Multi Platform - Windows, MacOSX, Linux

Moderators: XnTriq, helmut, xnview

Post Reply
cday
XnThusiast
Posts: 3976
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Proposal to add support for output of alternative versions of input files

Post by cday »

This thread outlines a possible way of extending XnConvert to allow output of multiple versions of the input files loaded. Currently, only a single file can be output for each file loaded on the Input tab, however requests are regularly made to allow output of alternative versions of each input file. A common use case would be the creation of images with different pixel dimensions for use on the web, although other possible uses can also be envisioned.

Overview
XnConvert’s present clear and intuitive interface provides an Input tab where the files to be processed can be loaded, an Actions tab on which the actions to be performed on each input file can be set, an Output tab on which the type of output required can be set, and a Settings tab on which certain general program options can be set. When the loaded files are processed, a Status tab enables progress to be monitored and any issues that arise to be viewed. Finally, the About tab enables the program version and other fixed information to be viewed when required.

The basis of the proposal to add support for multiple outputs is to add to the Settings tab a new option that, when enabled, opens a panel to the right of the existing program window on which the desired outputs can be set up. The default value of the new setting would be unselected. For convenience in describing operation, the existing program operation is referred to as Single output mode, the proposed new mode as Multi output mode, and the operation of converting the loaded input files into a set of output files as a Process.

When the Multi output mode option is selected:

1. The program window is immediately extended to the right to display a Control panel, which can be used to set up the required program operation.

2. The Input tab can be used in the normal way to load the files to be processed, and the Settings and About tabs may also be used if required.

3. The Actions and Output tabs can be used in conjunction with the controls on the Control panel to set up each required Process in turn.

An important practical advantage of the proposed interface is that when the program is used in the present Single output mode the interface is unchanged, so users familiar with the existing program will be able to continue to use it without even knowing that Multi output operation has been added.

The proposed interface also allows full flexibility in the outputs that can be created as each Process runs independently using its own Actions and Output settings, so there are no constraints on the outputs that can be obtained from the files loaded.

Control panel
The following controls will be required on the Control panel as a minimum:

1. A means to enter the number of Processes required, a minimum of five is suggested as users always ask for more than the number initially provided. :wink:

2. A means to select the Process to which the Actions and Output tabs currently relate.

3. A way to initiate conversion, such as a Convert all button.

Design of the Actions, Output and Status tabs
While users could be assumed to just ‘know’ that the above tabs apply to the Process currently selected on the Control panel, it seems better to modify their appearance in some way to distinguish them from the same tabs when Single output mode is selected to indicate that their function has changed.

One option would be to place the Actions, Output and Status tabs on a separate row below the Input, Status and About tabs to indicate their changed function.

Another option could be to modify the content of each tab in some way to indicate the change: some possible options might be to show the Process number so that the tab text becomes 1 Actions, 1 Output, 1 Status, etc. Other options could be to add some kind of symbol to the tabs, such as a small blue circle or rectangle, or to use a different tab text colour, remembering though that some people are colour blind.

Since in Multi mode conversion is initiated from the Control panel rather than from a tab, the Convert buttons on each tab of the main program window should be deactivated and greyed out to avoid possible confusion.

When finished with using Multi mode, the new Settings option added would be unchecked to deselect the mode, the Control panel would then close and the program interface revert to the default Single mode window. Job done!

Additional considerations
When it is required to output, for example, different pixel size versions of the input files for possible web use, each Process will operate entirely independently, resulting in some actions being repeated for different final output file versions. That would probably only be a practical issue when a large number of files were being converted when run time could be noticeably increased, but could be avoided if later some form of additional control were provided to allow the result of the actions from one Process to be used as the input for the next Process, possibly either copied or linked.

The design outlined could also allow someone who regularly uses a number of unrelated scripts to leave them loaded as separate Processes, avoiding the need to load a required script before running it again. That possible option might be implemented by providing an additional Control panel button that runs only the currently selected Process.

It is assumed above that the same Settings tab settings will be used for all Processes. While that is normally likely to be the case, if there could be a need to use different settings in different Processes, such as to enable multi-core operation only for a certain Process, the Settings tab could probably like the Actions and Output tabs be configured from the Control panel, provided that any possible conflicts have been considered.

The above outline is presented for consideration, while recognising that detailed examination may identify possible issues to be considered and hopefully resolved, or certain limitations on possible use.

Maybe with some thought XnConvert :D can be developed into XnConvert On Steroids :D :D ?
User avatar
xnview
Author of XnView
Posts: 43442
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Proposal to add support for output of alternative versions of input files

Post by xnview »

great, but how do you see the extended control panel to associate output/actions for each process, it's not clear for me.

Perhaps a better way is to create a group of action with output action
ACTION.jpg
Pierre.
cday
XnThusiast
Posts: 3976
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: Proposal to add support for output of alternative versions of input files

Post by cday »

xnview wrote: Tue May 17, 2022 11:11 am great, but how do you see the extended control panel to associate output/actions for each process, it's not clear for me.
cday wrote: Fri May 13, 2022 10:10 am Control panel
The following controls will be required on the Control panel as a minimum:

1. A means to enter the number of Processes required, a minimum of five is suggested as users always ask for more than the number initially provided. :wink:

2. A means to select the Process to which the Actions and Output tabs currently relate.

3. A way to initiate conversion, such as a Convert all button.
Explained in a little more detail:

1. I envisage, probably, a dropdown menu labelled Number of Processes on which the desired total can be set, for example 4.

2. A dropdown menu labelled Active Process which selects the Process to which the standard Actions, Output and Settings tabs currently apply.

3. A button labelled Convert all to start conversion when ready.

When conversion has finished, the Status tab of each process in turn can be viewed by setting the Active Process tab to that process.

xnview wrote: Tue May 17, 2022 11:11 am Perhaps a better way is to create a group of action with output action
Thanks for listening, your welcome suggestion requires a little study, and I think mine is possibly clearer, more intuitive, once it is explained... :wink:

My vision, by using the standard Actions, Output and Status tabs without any modification, with the Control panel open alongside on the right, I believe provides a clear, more intuitive interface that can be easily learned... :?:
cday
XnThusiast
Posts: 3976
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: Proposal to add support for output of alternative versions of input files

Post by cday »

Hi Pierre, I have had a bit more of a look at your proposal and had some questions, but meanwhile I have had a new thought regarding my proposed design.

When I asked whether it would be possible to use a setting on the Settings tab to expand the open interface to add a 'Control panel' to the right of the normal program window, you indicated it could be implemented. I wasn't sure about that as it certainly seems unusual.

I think that having the control panel open alongside the main interface provides a clear and intuitive interface for multi-output operation: the proposed control panel would initially consist of just a dropdown to set the required number of processes, a dropdown to select which active process is to be set-up, and the 'Convert all' button. One or two additional buttons or selectors might be added to allow the copying of actions from one process to the next, etc.

The new thought: If you have reservations about expanding the interface to add a control panel, another option might be to use the previously mentioned Settings tab option to open an additional tab to the right of the existing six tabs. The new tab could then contain whatever controls are required to set up the multiple output processes, the same controls that would be on the control panel. While a separate control panel which remains open seems a bit clearer overall, I think that a set-up tab could also work well enough if there is a reason for preferring it. :D

The advantages of either version of the interface as I see them are that the existing program interface continues unchanged, exactly as it is now, the multi-output set-up procedure should be easily learned, and the overall design concept provides full capability for any reasonable program use. :D

Addendum

Brief overview of the multi-output set-up procedure:

On Settings tab select the Multiple output checkbox.

On the Control panel or new tab:

Set number of required outputs (Processes);

Select Process 1;

Configure the Actions and Output tabs for Process 1;

Reopen the new tab (if used);

Select Process 2;

Configure the Actions and Output tabs for Process 2;

And so on...
cday
XnThusiast
Posts: 3976
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: Proposal to add support for output of alternative versions of input files

Post by cday »

Another day and another brilliant idea... :D

I will outline later how addition of a simple new 'control' to the control panel (or new seventh tab) described above could overcome a limitation of the basic design as originally proposed, further simplify set-up of multiple outputs, and so release the full possibilities of multi-output processing.
User avatar
xnview
Author of XnView
Posts: 43442
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Proposal to add support for output of alternative versions of input files

Post by xnview »

cday wrote: Thu May 19, 2022 7:52 am Another day and another brilliant idea... :D

I will outline later how addition of a simple new 'control' to the control panel (or new seventh tab) described above could overcome a limitation of the basic design as originally proposed, further simplify set-up of multiple outputs, and so release the full possibilities of multi-output processing.
Is it possible to make a mockup? :)
Pierre.
User avatar
XnTriq
Moderator & Librarian
Posts: 6336
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: Proposal to add support for output of alternative versions of input files

Post by XnTriq »

xnview wrote: Thu May 19, 2022 10:57 amIs it possible to make a mockup? :)
@cday: Best Apps to Create Mockups in Linux
cday
XnThusiast
Posts: 3976
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: Proposal to add support for output of alternative versions of input files

Post by cday »

The first post in this thread outlined a way in which XnConvert might be modified to enable the output of alternative versions of the files that have been loaded, an enhancement that has been regularly requested in particular for possible web use. Other possible uses can also be envisioned.

The basis of the proposal is to add a new operating mode in which the program is run multiple times with different Actions tab and Output tab settings for each run. A key insight in developing the mode was that with the addition of suitable program controls, the existing Actions tab and Output tabs could be used to enter the settings required for each run.

The new operating mode would be enabled by selecting an additional option added to the Settings tab. The default value of the new setting would be unselected.

An important feature of the proposed new mode is that a user launching the program to use it in the existing way will see only the existing program interface, and will be able to use it without even knowing that the new mode has been added.

The new mode would be managed from a control panel:

Control panel.png
Control panel.png (31.32 KiB) Viewed 1071 times
Key: [5] represents a value entered by the user, [o] a radio button, and [Text] a button.
Colour is used as a formatting aid in the absence of the aids normally available.

In the above control panel design:

Process refers to the creation of a set of output files when the program is run. The output files created will depend on the input files loaded, the Actions and Output settings entered, and the Settings tab settings.

Active process is the process to which the Actions tab and Output tab currently relate, on which the required Actions and Output tab settings for that process can be entered.

Setting up the program in the new mode would consist of first setting the required number of processes, then setting the 'Active process' to '1' and setting up the Actions and Output tabs settings needed for the first set of output files, then setting the 'Active process' to '2' and setting up the Actions and Output tabs settings for the second set of output files, and so on.

The proposed control panel design supports operation in either of two modes:

In Standard mode each process runs independently, reading the input files that have been loaded, applying the specified actions, and producing the specified output files. Options are provided to output the files created to a separate folder for each process, or all to the same folder. Options are also provided to run either all processes, or only the currently selected active process.

As well as allowing complete flexibility in operation, the design outlined would also allow a user who regularly runs a number of standard conversions to leave them loaded as separate Processes, allowing a selected process to be run immediately when required, without the need to load a saved actions script and set up the corresponding output tab.

In Cascade mode the Actions specified in a particular process are applied to the images created in the previous process, rather than to the files loaded on the Input tab as in Standard mode. For example, the actions applied in Process 2 are applied to the images that were created by the actions in Process 1, the actions applied in Process 3 are applied to the images created in process 2, and so on.

When different size versions of images are required for web use, this mode would simplify set up by avoiding the need to repeatedly set up actions already performed in an earlier process, and also minimise the program run time when converting a large number of files by avoiding unnecessary repetitive processing.

It was originally anticipated that the control panel required for the new mode would be placed on a panel to the right of the existing program window, which when the new mode was enabled would expand in width to create the extra space required. The vertical orientation of the example control panel above would be ideal for that location.

Another possibility, if there is a reason for preferring it, would be to place the controls required for the new mode on an additional tab to the right of the existing tabs that is displayed only while the option that enables the new mode is enabled. That would however mean that as the controls would not be displayed continuously and be accessible at any time, so the additional tab would have to be reopened each time that control panel setting needed to be changed. Operation could nonetheless probably be easily learned.

For considerations relating to the detail design of the Action and Output tabs when the new mode is enabled, see the section of the first post 'Design of the Actions, Output and Status tabs'.

It is believed that the proposed new operating mode would be a useful addition to XnConvert, would meet a currently unsupported need, and might be reasonably easily added since it might be implemented primarily by reusing and linking existing code modules.

A note on the detailed program flow in Standard and Cascade mode:

In Standard mode each process would run entirely independently, so Process 1 would read each loaded image in turn, apply the specified actions required, and then output the required file. Then Process 2 would be run, read each loaded image in turn, apply its own actions and output settings and output the required files, and so on.

In Cascade mode, intended to provide a simple way to create the 'web' images regularly requested, where the each image is required to be output with, for example, different pixel dimensions, the program flow envisaged is:

o Process 1 would load the first image, apply the specified actions and output the first required file;

o Process 2 would load the first image bitmap created by Process 1 (in place of the loaded file), apply the specified additional action(s) required and output the required (probably resized smaller) file;

o Processes 3 and 4 (for example) would each apply an action or action to the bitmap created by the previous action, and output the required file.

o When the first loaded image has been processed by Process 1 to 4 (for example) the second loaded image would be processed in the above way, and so on until all loaded images have been converted. So the program flow would differ from that of Standard mode but still remain simple.

I hope that is clear! I think the above proposal overall could greatly enhance the power of XnConvert, could have a clear interface that can be easily learned, would importantly use the existing Actions and Output tabs without modification, and would probably not be too difficult to implement.


@XnTriq: The illustration was produced using LibreOffice Writer, as it provided a familiar way to allow accurately aligned text to be created, and supports output to PNG format.
cday
XnThusiast
Posts: 3976
Joined: Sun Apr 29, 2012 9:45 am
Location: Cheltenham, U.K.

Re: Proposal to add support for output of alternative versions of input files

Post by cday »

Additional information on the anticipated operation of the program in Standard and Cascade modes has been added to the end of the previous post. :D
Post Reply