Batch processing smart output directory handling

[dosdan]

It would be nice if batch processing could output to a subdirectory off the directory the tag files are located in. Say you are running a batch resize on photos in a directory called C:\Photos1 and then later on run it on C:\Photos2. In each case you want the result to go into a subdirectory called Processed (e.g. C:\Photos1\Processed; C:\Photos2\Processed). Currently you have to adjust the output directory each time. It would be nice to be able to:

1. Work with an subdirectory off the original files directory (relative addressing), rather than having to specify the full output directory pathname.

2. Have XnView automatically create the subdirectory if it does not exist.

3. Be able to nominate the subdirectory name e.g. Processed; Web; Photo Frame. If the subdirectory name was saved with the batch processing script then you could run two batch scripts on the same tagged files and create two separate output subgroups, say one for printing, one for the web.

Dan.

[marsh]

Use this in output directory field:

Code: Select all

$/processed/

It will automatically create target subdirectory, as named.

[dosdan]

Thanks for that. It will come in very handy. I think I can edit existing script files to use this string (under Windows):

Code: Select all

output_path( $\processed )

Is there a way of inserting the date in YYYYMMDD format in the directory name?

Dan.

[marsh]

Thanks for that. It will come in very handy. I think I can edit existing script files to use this string (under Windows):

Code: Select all

output_path( $\processed )

Is there a way of inserting the date in YYYYMMDD format in the directory name?

Dan.

... haven't read anything about that.

[dosdan]

There seems to be a problem using $\processed as the output destination with Windows & XnView 1.96. It only operates correctly with a single file in the batch list. Once there are two or more files in the list it errors on both files. Fully specifying the output destination fixes it.

[marsh]

There seems to be a problem using $\processed as the output destination with Windows & XnView 1.96. It only operates correctly with a single file in the batch list. Once there are two or more files in the list it errors on both files. Fully specifying the output destination fixes it.

I use both leading and trailing forward slashes: $/converted/

[dosdan]

I tried all 4 permutions before posting:

Code: Select all

$\processed
Error creating the file <$\processed\Landscape Test Image.jpg>

$\processed\
Error creating the file <$\processed\Landscape Test Image.jpg>

$/processed
Error creating the file <$/processed\Landscape Test Image.jpg>

$/processed/
Error creating the file <$/processed/\Landscape Test Image.jpg>

I also tried image filename without spaces.

[marsh]

There is an option which needs to remain unchecked to avoid error:
[ ]Keep subfolder structure

[dosdan]

Yes, I noticed that the maintain subdirectory stucture option had to be unticked. Problem I had was that I would untick it, save & overwrite the old script and then, when I reloaded the script file, it was ticked again. This modify/save/reload cycle continued until XnView faulted. Turned out that high-order ASCII had been written as the "output"(params). When I recreated the batch from scratch, it worked.

Thanks for your persistant help. It kept me trying.

Here is the script. It resizes photo files to 787x576 to suit the PAL TV aspect ratio. I use it to create versions of photos that I can use in a slideshow program:

Code: Select all

resize( 1 lanczos 787 576 -1 0 0 )
canvas( 0 787 576 4 0 0 0 0 )
settings( 0 0 0 0 0 1 )
output_path( $\processed for slideshow )
output( jpeg 100 1 1 0 0 0 1 )

Dan.

[helmut]

I'm not 100% sure, but I think there's a problem with the spaces in the folder name and/or filenames. Could you please try just "$\processed" as output folder?

Note:
From what I can see, backslash and slash can used both.

EDIT:
Copied your conversions script, saved it as "xnview.xbs", and used it for conversion. The problem did NOT occur. Hmm.

[dosdan]

Helmut, the script now works. The problem was a corrupted script with high-order ASCII saved as the params for "output( )". The general problem has been instability during batch procession, either closing the program, or in the case I mentioned, actually corrupting the script file. I'm hoping the next version is more stable (as least for me).

Dan.

[helmut]

... the script now works. The problem was a corrupted script with high-order ASCII saved as the params for "output( )". ...

Good to read that it works, now. Could you provide some more details to reproduce the problem? What do you mean by "instability"?