Extract multipage-TIF and file-enumeration

[Peter2]

I extracted 18 multipage-TIF, my definition of filename was "{Filename}_#"

Now the result is (seem to be new in 1.10) that the enumeration counts both "number of file AND number of page".

Result:
a.tif ->
- a_1_1.tif, a_1_2.tif, a_1_3.tif
b.tif ->
- b_2_1.tif, b_2_2.tif, b_2_3.tif, b_2_4.tif
c.tif ->
- c_3_1.tif, c_3_2.tif

At the moment I'm not sure if it is a bug or a feature, but I think it is only necessary if there is ONLY enumeration; when the {filename} is used it is not good.

Peter

[xnview]

What will be better?

[Peter2]

What will be better?

Good question - writing this answer I see the problem to make a difference between file-numbers and sheet-numbers.

For multipage(!!)-files I see no advance ("Cui bono?") at the moment , but more confusion

- When I extract "3 files with 3 commands" I get other results then with "3 files in 1 command".
- Extracting numbered files ("1-5-02-032.tif") could cause confusion.

Maybe the best way is a standard solution: user defined settings to
- enumerate "file-number and sheet-number" ?
- enumerate "only sheet-number" ?

I don't know.

Peter

[Peter2]

...
- When I extract "3 files with 3 commands" I get other results then with "3 files in 1 command".
....

Yesterday I got my first real problem.

a) At first I extracted a series of files: a.tif, b.tif, c.tif
So I got b_2_8.tif

b) Then I extracted b.tif alone:
I got b_1_8.tif

-> same file, other names, no overwriting.

I think it should be changed..
What is the opinion of the user users?

Peter

[marsh]

What about reusing the duplicate dialog from batch rename?

[Peter2]

What about reusing the duplicate dialog from batch rename?

You mean to integrate this dialog in the "filename-section" of XnConvert?

Peter

[marsh]

What about reusing the duplicate dialog from batch rename?

You mean to integrate this dialog in the "filename-section" of XnConvert?

Peter

Yes, from MP's renamer (if I read topic correctly).

[xnview]

Could you tell me exactly what do you make to understand?

[marsh]

Could you tell me exactly what do you make to understand?

The topic is a puzzle to me now.

[Peter2]

The topic is a puzzle to me now.

Yes, I'm confused too. So let's start again.

I have 5 multi-page-TIF:
A.tif,
B.TIF,
C.TIF,
D.TIF,
E.TIF.

My outout-definition is "{Filename}_#"

XnConverts counts the files and uses "internal numbers" 1, 2, 3, 4, 5

The resulting files get the number "{Filename}_INTERNAL_PAGENUMBER"

Example:

Code: Select all

A_1_1.tif
A_1_2.tif
B_2_1.tif
B_2_2.tif
C_3_1.tif
....

Mabe it is my fault, but I don't want and don't need the INTERNAL number, because

• It is not necessary. Who needs it why?
• It is confusing for the user. Where does it come from?
• It is dangerous. If I repeat the conversion only with files C.tif and D.tif, then "C" will get the internal number "1". So I will get a file "C_1_1.tif" instead of overwriting the existing....

I hope it is clearer now.

Peter

[marsh]

With another filename template (or complete lack of one), the internal frame number seems needed.
v.1.98's extract into directory is more informative about this:
image_page_001.bmp
image_page_002.bmp
image_page_003.bmp

That would be much clearer than XnC, where we have only the number:
image_1.bmp
image_2.bmp
image_3.bmp
(this looks very confusing along with existing "_#" in template)

So far, the result is not overwritten when option to rename is used:
image_1_1.bmp
image_2_1.bmp
image_3_1.bmp


This would be more informative to me:
image_frame001.bmp
image_frame002.bmp
image_frame003.bmp

[Peter2]

Hi marsh

only ONE = 1! number is needed. But as described above I get internal-job-number (bad) and the frame-number (good).

Peter

[helmut]

... At the moment I'm not sure if it is a bug or a feature, but I think it is only necessary if there is ONLY enumeration; when the {filename} is used it is not good. ...

Placeholder <filename> should contain the original filename, nothing else. And I think this is what XnView currently does. My guess is that in your example for multipage tiff files, XnView's duplicate handling is applied and therefore, the duplicate suffix '_##' is added (click on button "Duplicate..." in batch rename dialog to see the current setting for duplicate handling.

As a simple solution/handling the duplicate handling is o.k.. For a flexible renaming for multipage files, more placeholders are needed:

Placeholders
<Input Number>= Number of the current input file
<#> or <Output Number> = Number of current output file
<Page Number> = Number of current page in image

+ two settings
Two settings, preferable with user interface, are also needed:
1. Page number prefix (default: -)
2. Page number suffix (default: <none>)

Example:
abc.tiff containing 2 pages
def.tiff containing 1 page
ghi.tiff containing 3 pages

With a filename template:
<filename>-<Input Number><Page number>

Result would be:
abc-1-1.tiff
abc-1-2.tiff
def-2.tiff <-- Note that page number prefix, page number, and page number suffix are only applied if file contains multiple pages.
ghi-3-1.tiff
ghi-3-2.tiff
ghi-3-3.tiff

With a filename template:
<filename>-<Output number>

Result would be:
abc-1.tiff
abc-2.tiff
def-3.tiff
ghi-4.tiff
ghi-5.tiff
ghi-6.tiff

Peter, would this solve your problem?

Notes:
- Placeholder names should be discussed, personally I'd prefer something like <# input> to <Input number>, for example.

- Not 100% sure whether <#> should map to input number or to output number. Currently it seems to map to input number, otherwise the result in original post would have been different. It might be better to map it to output number to avoid collisions when converting multipage using a simple filename template.

- Helmut

[Peter2]

...
Placeholders
<Input Number>= Number of the current input file
<#> or <Output Number> = Number of current output file
<Page Number> = Number of current page in image
...

If "Inputnumber" and "Outputnumber" are optional it would be OK for me. But it must not appear always.

Peter

[xnview]

Please check XnViewMP 0.48