XnView Software

XnView MP 1.4.1 64bits
Windows 11 64bit (22H2), display resolution 3840x2160, win scaling 150%

Batch convert
Persentage of file's size change is inverted for some reason.
I guess it shall be like this:

• if file size increased - positive %

• if file size decresed - negative %

it's a % to show the decrease, so if file increased % is positive

xnview wrote: Thu Jan 26, 2023 1:34 pm it's a % to show the reduction, so if file increased % is positive

I don't see the change declared as the 'reduction'?

I agree with the OP, 'change in filesize' seems more intuitive, so 151.24 KIB -> 1.64 MiB (+1084%).

On further thought, isn't the sign (- or +) actually unnecessary?

Why not simply state the percentage change in filesize:

For example, 63% indicates a decrease, and 310% indicates a substantial increase?

cday wrote: Fri Jan 27, 2023 10:07 am On further thought, isn't the sign (- or +) actually unnecessary?
Why not simply state the percentage change in filesize:
For example, 63% indicates a decrease, and 310% indicates a substantial increase?

as for me, it is better to have negative values as clear indication of size reduction
scale starting from 0% a bit easier to understand/operate when comparing two values
also 100% have some extra, unnecessary connotation in that case

user0 wrote: Fri Jan 27, 2023 2:30 pm

cday wrote: Fri Jan 27, 2023 10:07 am On further thought, isn't the sign (- or +) actually unnecessary?
Why not simply state the percentage change in filesize:
For example, 63% indicates a decrease, and 310% indicates a substantial increase?

as for me, it is better to have negative values as clear indication of size reduction

Is it indicated anywhere that the parameter displayed is 'size reduction'?

Without that information the display could be hard to understand.

well, i thought it is general concept that does not require clarification: value1 -> value2 (diff%)
but there is also a hint in the end - total "File size ratio:"

user0 wrote: Fri Jan 27, 2023 5:59 pm well, i thought it is general concept that does not require clarification: value1 -> value2 (diff%)
but there is also a hint in the end - total "File size ratio:"

I shouldn't really debate with you too much when it is your thread, and I didn't really ever start at the beginning!

But, for what it's worth:

Isn't "File size ratio:" clearly indicated by a positive value, without a sign, that is less than one for a reduction, and greater than one for an increase in file size? That seems sufficient, and to me probably clearer.

For that matter, is there actually a good reason for displaying anything other than the source and output file sizes?

But if a percentage value is required, I agree with you that the signs would be better reversed.

Further:

Might 'Increase' or 'Decrease' or even 'Larger' or 'Smaller' without a +/- sign avoid the problem, and actually be clearer?

i find difference in precentage quite useful, it allows to quickly read the story.
the only issue is sign that shall be reverted

user0 wrote: Sat Jan 28, 2023 10:29 am i find difference in precentage quite useful, it allows to quickly read the story.
the only issue is sign that shall be reverted

Ok, i'll change it

1.4.3
it has been changed for individual image, but still remain unchanged in Total File size ratio

For compression efficiency, a positive ratio is normally used. (Such as 1.30X, if the original file is 1.3 times larger than the compressed file.)

However, such a scope is specific to data compression only.

XnViewMP's batch converter... "converts". It's main scope is not simply "attempted compression". In fact, some files may end up larger.

Therefor, I agree with the proposal that the result should be displayed in a percentage change (+ for increase in size, and - for decrease in size).

This thread has motivated me to file a useful feature: viewtopic.php?f=60&t=44904

Thanks to your detailed description I can reproduce the problem.

This problem is supposed to be fixed in XnView MP 1.4.4. Please check and confirm the bug fix here.