Reported Custom Selection width/height change

[travelgirl]

Irfanview 4.1 works correctly.
Bug appears in Irfanview 4.2 and 4.25.

* Select large photograph (example here is Canon 5D, 5616 x 3744 pixels).
* Image is Screen-Size (all pixels reduced to 1621 x 1081 on 1920 x 1200 screen)
* Bring up custom selection
* select width of 1800, height of 1200
* Apply to Image
* Check size of selection on caption bar
* re-enter custom selection dialog
* look at width and height

What happens is that the numbers have changed, off by as little as one pixel, as many as three. In this example, the selection is 1801 x 1198. It happens whether i use the actual ratio or a selected. X and Y offset are 0, so borders/boundaries are not an issue.

If I enter custom selection while image is 1:1 pixel for pixel with screen (I see about 1620x1080 of the image at any one time), the width and height USUALLY do NOT change. However, this won't work for me: 98% of time I work with images much larger than a screen (heck, larger than several screens), where the selection crop itself is larger than the screen, and I don't always want a selection to start at 0. If I can't see the selection rectangle, I can't know that I'm making a proper selection where it needs to be made. Even if I make a default selection, by returning the image back to screensize I lose the rectangle and the selection.

This worked with version 4.1, and has failed with every version I've tried since. HELP!

[Skippybox]

There have been many threads on this if you search around. Basically, when an image is zoomed in IrfanView, there is a imprecision between screen and image, so you get these little errors.

Your best bet is to save your on-screen selection using custom selection's (SHIFT+C) Save Values button. Now press CTRL+H (Original size), SHIFT+C (custom selection), CTRL+Y (Crop).

You can make selections in 1:1 mode by using your PgUp, PgDwn, Home, and End keys to quickly maneuver around the image.

[travelgirl]

i'm sorry, but that's a horrible workaround when you are dealing with images that are multiples of screen size. this is especially true if the product feature worked (which it did) until 4.2x arrived.

this leads me to believe that the code architect either didn't understand fully what his/her change would mean (and is refusing to fix it for any of several reasons i could think of), or there is a bug in the code i could drive an aircraft carrier through (and they are refusing to fix it for any of several reasons i could think of).

i would agree with you that 1:1 image cropping works, but only when you are dealing with images that are smaller than the screen. for cropping today's digital photographs, where the crop itself is larger than a power user's hi-def screen (very likely with today's cameras), i'm going to call this a bug.

it worked in version 4.1. it does not work in 4.2x. if the coding team wishes to punt this (and it sounds like it has), so be it. i'll have to find another program to do simple crops. my workflow overhead gets larger, as does the research time to find such a program, but i'll have to deal with that.

i hope version 4.1 is always available... i won't upgrade irfanview again until this is fixed. i can't.

[Mij]

There is no need to go back to v4.1. Just go back to the Zoom method of v4.1.
(Options> Properties > Viewing > Zoom calculation method = Fixed values).

There are still errors in where the selection is shown. There have to be. The sides of the selection box are always one pixel of the screen wide. With large images that one pixel of screen may represent many pixels of the image itself, so at anything less than 100% zoom it cannot precisely represent the pixels of the image that will be exactly at the crop boundary, but if you use the Fixed step zoom values, then you will usually find that the image you crop is what you set it to.

Note that the zoom ratio you get from a Fit to window or Fit to screen is generally not one of those carefully selected zoom steps. You need to press the + or - key to go Up or down to the nearest one.

The other Zoom calculation method options were introduced at the request of other users who have needs different to yours. Do just pause a while before you sound off about the program developer.

[travelgirl]

"There are still errors in where the selection is shown"

Problem is, there were never selection errors before. They occur now, even with your workaround. Example: I selected 3000x2000 through the dialog, with all zoom calculation methods selected one after another, received 3001x2001 and 3001x1999. So, I follow your advice and "+" once to change the onscreen zoom. I have no idea why zoom calculations have anything to do with crop selections, but it appears they are now connected. I Select 3000x2000 for crop and lo, I receive a perfect 3000x2000 crop. Using this new cropped image, now I use the dialog to select 2100x1400, and I receive 2101x1401.

There is no consistency. Having to get an error, then do a workaround, in order to see what version 4.1 did without thinking seems to be a great waste of time.

I need exact numbers for sizes. When I enter a specific number, the program should give me exactly those numbers if (as you say) FIXED VALUES is the version 4.1 way of doing things. My problem: I can't be off ANY pixels. Even with FIXED VALUES checked and supposedly active, IView has problems now where none existed before. Therefore, I cannot use the newer versions of IV because they have a bug in selection.

Yes, your workaround might work from time to time, but it is not consistent. There's a bug here.

I'd like to suggest that the real values for "Fit to Window / Fit to Screen" must be among those carefully-selected zoom steps. There are not a lot of fixed screen sizes that need to be adjusted: 1920x1200 should default to 1622x1081, as an example, because 1622x1081 is the displayable area, NOT 1920x1200. Etc... This, I believe, is where the bug really lives.

"...anything less than 100% zoom, it cannot precisely represent..."

any reason IView can't make the selection from its internal view of the whole of the image? In other words: my screen displays a fit-to-screen of 1622x1081, but internally IView knows the full-sized image is whatever it is (in this case, 4368x2912). Can't IView have a method of selecting that works using the internal uncompressed copy of the displayed image? Is there a reason why IView, given an X and Y, can't simply crop exactly "width" and "height" pixels from that internal uncompressed copy, then display what it can with "fit-to-screen/window"?

I do this for a living (computers and photography), and have been for longer than many readers here have been alive. You are right: it was silly to denigrate the developers. However, just as correct is my view: there's a bug here, or I'm not completely understanding everything the new version does, and so far, no one (including yourself, though i do thank you for trying) has given a simple and consistent workaround for what used to work perfectly and without fail before version 4.2x...

You need a tester? I'm a tester most developers hate, because I find ways of exercising their code in ways they usually don't dream of... Having been a commercial coder, I know code is perfect. Having been a professional tester, I know code has holes in it large enough to drive tanks through.

[Skippybox]

No one here has to provide anything, we are simply volunteers. There are countless threads to respond to, and this one is no more important than any other.

If you really were a professional tester, as you say you were, you would know that version 4.10 and before did have the error. I can easily produce it.

The problem is you assume that the program has to be error free and perfect. IrfanView software is provided "as-is". No warranty of any kind is expressed or implied. So, the author can do what he wants, how he wants. If he doesn't think it is important to anyone or worth the time, then it doesn't get done. If you don't like, you can use something else.

You say you were a commercial coder, why haven't you written a program without this problem to use? You seem like you desperately need IrfanView and version 4.10. And why are your images so large anyway? Most digital cameras have wasteful resolution. You should get something that captures more detail, not pixels. There are 1MP SLRs that make better photos than some 10MP cameras. If your workflow is increasing, why don't you tell your boss to get you some better tools for efficiency? Are you getting compensated for your efforts anyway?

Cropping cannot be exact, unless it is working on an original image. Crop in IrfanView does not do that, it is based upon a selection. If that selection is not exact, then the crop cannot be either. The reason the selection is not exact is because it is applied to the image you are working on in the window. That means, that a selection is not stored in image coordinates, but screen coordinates. Your applied values get translated to and from screen coordinates, leading to averaging imprecision.

The only way to get consistent results is to work in 1:1, where image coordinates and screen coordinates are equal. Anything else will produce an error or sometimes produce error. That is why zoom matters. Working in image coordinates will not completely solve this, because most of the time you are starting with screen coordinates, which are usually an approximation.

What is so horrible about my workaround? Workarounds are never easier or faster than what they replace. You still get to make your selection when the image is fitted to the window. All your doing is saving it, so it can be applied when you show the image in original size. You probably could make a macro out of that. But, I'm guessing you'll just use 4.10. Why, I don't know.

[travelgirl]

for what it's worth, your workaround assumes i'm already cropped: "now press control h (original size)". i'm working with original size, which in my case starts at about 3000x2000, works its way up to close to 6000x5000 (depending on the camera). thus, your workaround does not work for me.

yes, i know some point-and-shoots can create awesome photography. however, i'm using what i use because i have said equipment (better or not is a point of view fight i'm unwilling to get into).

if the bug were there prior to 4.2x, i never saw it.

i assume nothing regarding error free and perfect. i work towards an ideal, and until very recently, IView provided about as error-free a user experience as i've have with ANY program, my own included. this bug, however, gets in my way, and i've requested a fix. if it doesn't happen, as i said before, i'll stick with what works until something better comes along.

"... the selection is not exact is because it is applied to the image you are working on in the window..." -- precisely. and it shouldn't, but that is simply my opinion. not saying you DO, but you SHOULD crop from the largest image available, and that should be the internal image IView keeps around in memory, not what is displayed, when you work to crop a selection. in this way, you NEVER have a precision problem...

FYI - screen coordinates should NEVER be an approximation. ever. they may be based on faulty math, but they should always point to a specific point in the original image. so, when you apply 3000x2000 to a SPECIFIC image XY point, it should always crop exactly 3000x2000 from the original image. it shouldn't have to do several additional math transformation to figure out where that point might be based on what's displayed onscreen.

zoom and selection should be decoupled. they are not. that's my complaint.

given i'm in the minority, i'll simply fade into the background now. thanks for trying...

[Bhikkhu Pesala]

It is time to lock this thread — its going nowhere.

[Sam_Zen]

Fading out of sense anyway.. never - always - perfect .. well..