XnView Software

It looks quite close to these reported bugs (but these topics seems to describe more then one bug). The topic "Orientation tag and lossless jpeg crop" seems to be exactly the same bug (it is noted that there must be more than one jpg and to flip between them to reproduce).

I'm using XnView Classic ...

The bug leads to irreversible data corruption.

The bug is occur from time to time when jpeg-cropping photos with have rotation tag (often 90 degrees).
When corruption occures, the final crop border position is seem to be rotated to originally selected.

How to reproduce the bug (not clear ...

I've got this popup error every time XnView is started (but then it works fine).
I've found that plugin webp.dll causes this error (seems to be compiled without XP compatibility). Substitution this plugin to older version (i.e. 2.33) fixes the problem.

As for me, it is obvious without any conformations that choosing operations with jpegs mean that only jpegs would be processed (I can imagine only few cases when conformation may be useful rather then annoying).
But I admit that most of users may think otherwise.

For example, I want to autorotate by exif tag jpg images from my camera. I select all the files in the folder and - oops! - the corresponding jpg-operations are disabled.
The reason is one or more non jpg files are in the selection (often raw or avi) which should be then manually deselected ...

I've deleted the file. :(
Such a bug I've noticed in previous versions too (not often but from time to time). This makes me to rotate images by exif first before cropping to avoid wrong cropping.

In previous versions bug was not reproducible (restarted XnView croped the same file correctly). Maybe ...

For example, I have after photosession a folder with 100 images only 10 of them were shot with vertical camera orientation.

1) I select in XnView all of the files in the photosession folder. (This is reasonable, because to select one-by-one only 10 "vertical" images is uncomfortable and time ...

And it makes rotation of a few unrotated files in a big folder to be very slow !

I got a folder with images from a camera. Some of them have exif information about rotation and I want to rotate them.
When I select all of the images in the folder and then command XnView to rotate them by exif tag ...

I found the following bug with irreversible losses of the image .
1) XnView is set to display JPGs autorotated by exif-tag.
2) A selection is made.
3) The jpeg-crop is used.
The result of crop is wrong (cropping height and width are exchanged) when on displaying the image is rotated!
The bug is ...

Thanks, it works!

Sorry, I misunderstood this option, so slow performance just seemed to me.

But is it reasonable idea to cache more then one image?

xnview wrote:You would like to zoom a selected area?

Yes. An option to proportionally enlarge the selected area to fit the screen.

xnview wrote:Do you have enabled previous caching?

There is no such an option in XnView. There is only "keep current image in cache" option, which means that only seen (but not unseen!) previous image would be cached. Then it leads to much slower performance in backward-order image browsing.

I encountered that text settings of displayed information are quite inconvenient.
Just look at the image below:

So, using writings with framing could solve the both problems of visibility of XnViev.

Sometimes it is very useful to zoom selected area of image to screen, but it seems that there is no way to do it in XnView currently.
Adding this option to right click menu would be quite useful.