XnConvert 1.8 - batch resize - bug?

[mustbeit]

What is wanted:
Batch reduced images height to 1080 pix, whether they are in portrait or landscape, but if their height is already 1080 or less, do nothing.


open XnConvert 1.8
1/ select an image having a height say of 1080 pix.

2/ In "Action" add "Resize" as filter, NO other active action
Select "Height" (Hauteur)
size 1080 (viz, the same height as the input image)
select "reduce only"(réduire seulement)

3/output
same folder, add _ as prefix.

4/ Execute.

Results:
Hashing input and output show different signature

Expected behaviour
output image must be identical to input, as only filter is resize and parameters exclude action.

Bug?

Thanks

P.S. At execution I get "The 'CPU Core" settings is disabled, can't be used with 'Ask' mode, or multipages, PDF files"

[xnview]

the resize is not made, but file is written in the format, not copied. So for example with jpeg, you can have a re-compress

[mustbeit]

I don't understand the answer.
If, in this example if I take a jpeg of 1080 height.
I would expect with the settings do nothing in that case.

Because
Suppose, I have 10 jpeg: 6 have a height > 1080 and 4 are of height 1080
I overwright the original jpeg with the reduced one.

Now if I batch select the 10 jpeg it ought to process only the 6 larger than 1080
In term of CPU & HDD it also also much faster, especially if one consider not 10 jpegs but hundreds.
Setting the resize to 1081, would do the job for the 4 of height of 1080, but the 6 others would be resized to 1081

[xnview]

it's a batch convert, output files are always written

[cday]

it's a batch convert, output files are always written

Currently all input files are opened and then resaved even if no actions are selected...

A request has been made to add a 'conditional conversion' option, in effect to 'only convert if a specified condition is satisfied' which would avoid resaving unchanged files, and also speed up conversion when processing a large number of files.