XYplorer Beta Club

Images with a huge resolution take too long to get previewed (very understandable)

file: PNG
image resolution: 1247 x 32124

I propose a placeholder preview image could instead get loaded for any image files that have super-large image dimensions. Or just some other clever method could be in place to prevent app freezes/pasues of XYplorer

(notice: Windows users who have right-click contextual image viewer's such as XnView Shell Extension, could experience an even longer freeze (not crash) with Windows Explorer)

here is the same Image file for download and tests (extract it from RAR archive):
24 mb

You mean XY should not display the image but instead display some placeholder image?

BTW, sendspace is dangerous crap site. I highly recommend NOT to click on links to sendspace!

admin wrote:You mean XY should not display the image but instead display some placeholder image?

Yes that's exactly what I mean...So there could be a quick instantaneous background reading of image resolution in the file header to determine if the preview is too hefty to load so that a placeholder image can be used instead. A black/white checkboard pattern might make a nice placeholder.

I think a separate tickbox setting would be suitable for this.

btw, Sorry about Sendspace - I've always found it quick to upload to there....I hope you (Admin) downloaded and extracted the RAR to analyze the image

I second this.
If previewing an image would make a program to hang for long, it's better to let the control in user's hands rather than frustrate him/her to sit and wait as if the program has hung to the stage of killing it via Task manager. Maybe there could be a setting for that - for many it's acceptable to wait few seconds if they preview moderate sized images for the most part.
Me too, I hate when an app hangs for several seconds while doing something. Most do not process messages meanwhile and you can see (Not Responding) in the titlebar, I don't know whats the case with XY because I don't preview large images .

haddy wrote:Yes that's exactly what I mean...So there could be a quick instantaneous background reading of image resolution in the file header to determine if the preview is too hefty to load so that a placeholder image can be used instead. A black/white checkboard pattern might make a nice placeholder.

I think a separate tickbox setting would be suitable for this.

btw, Sorry about Sendspace - I've always found it quick to upload to there....I hope you (Admin) downloaded and extracted the RAR to analyze the image

Also the format icon could be used, since a black/white checkboard (well, grey/white) is already used to distinguish the alpha channel in png's and similar (and it's the standard meaning of such checkboard in image graphics).

There is a tweak for this: PreviewMaxArea. This would limit preview to images with maximally 12 million square pixels (3000 x 4000):

Thanks for the Ini tweak However I feel that there should still be a UI tickbox option for this would which act upon this same tweak (perhaps also with a user input to specify the exact maximum HxW pixels)

haddy wrote:Thanks for the Ini tweak However I feel that there should still be a UI tickbox option for this would which act upon this same tweak (perhaps also with a user input to specify the exact maximum HxW pixels)

Yes, might be useful. Actually I just discovered a little bug in connection with PreviewMaxArea: the preview is still done by the shell under some circumstances. Hm...

.

admin wrote:

haddy wrote:Thanks for the Ini tweak However I feel that there should still be a UI tickbox option for this would which act upon this same tweak (perhaps also with a user input to specify the exact maximum HxW pixels)

Yes, might be useful. Actually I just discovered a little bug in connection with PreviewMaxArea: the preview is still done by the shell under some circumstances. Hm...

Fixed.

Next version will handle PreviewMaxArea much cooler... You will get a button to preview them now.

grindax wrote:

admin wrote:Actually I just discovered a little bug in connection with PreviewMaxArea: the preview is still done by the shell under some circumstances. Hm...

Could that have anything to do with the fullscreen viewing of images problem, where there's sometimes a small gap at the bottom and/or right?

Not at all.

Hi again,

Even with the "PreviewMaxArea=12000000" Enabled, Im still finding that some images slip through this net and still have delaying previews. Some examples in my tests are:

PNG image @ 1247x9265
PNG image @ 1247x6652
PNG image @ 667x10428
PNG image @ 700x7345
PNG image @ 1116x3038


But obviously for these isolated cases it would just be a discretionary requirement of reducing the '12000000' figure down to lower figures, wouldn't it?

----------------

Furthermore I still think that "PreviewMaxArea" should have a UI frontend whcih would look like this:

So from the picture mock-up, you will see that if a user uses the pre-configured Qt spinbox to go Up/Down from 12000000 pixel - then this change would be shown in real-time in a greyed out text that shows what the pixel size of '1200000' would be.

I would most definitely use this setting much better if it was through UI

Yes, but I had something similar years ago and removed it because lots of users simply did not want any limit. Your are the first asking for this in years.

admin wrote:Yes, but I had something similar years ago and removed it because lots of users simply did not want any limit. Your are the first asking for this in years.

But maybe with the new button allowing to preview also bigger images this might have changed a bit?

Though I must say: I usually have no problems, as I don't have much of these very big pictures, just a few panoramas...