Requested Pixel-precise selection rectangles

[dlanor]

Currently IV does not allow the user full control of the pixel coordinates of a selection rectangle. It may appear to do so, as no visible complaint will ever result from entering any coordinates (by which I mean X, Y, Width, Height), but the coordinates accepted internally and used by IV in the processing of that selection rectangle will often differ by single pixel offsets either way. This error can also be inspected directly by the user, by simply pressing Shift-C to re-open the selection dialog, which will then display the incorrect coordinates accepted by IV. But all attempts to correct this error will again produce exactly the same error...

In many cases the effect of this error will be invisible, but in other cases it will produce glaringly ugly results.

Just as a simple example, consider the following situation. I am composing a picture from several rectangular elements, including the base picture to contain the others. Let's say that this picture contains an ugly section in a glaring red colour, which I want to cover up by pasting in two rectangular logos cut out from other pictures earlier. Those must be fitted together with pixel precision so that neither loses any of its edge details and so that none of the glaring red of the original picture shines through at the 'joint'.

For this kind of processing it is a 'toss-up' whether IrfanView will be able to do the job correctly, with the odds going against success, mainly because each rectangle has four coordinates which IV must 'accept' unchanged to ensure a perfect fit. Fortunately some of the corner coordinates don't really affect this kind of 'joint', so they don't matter then, but unpleasantly often it is the corners that do matter which IrfanView fails to accept.

For all kinds of cut-paste work it is crucial that the user can control all four coordinates of a selection rectangle, without any 'censorship' by the program.

I believe that the 'censorship' which currently occurs is just a side effect of some scaling work done to present the picture on screen, but it is completely unacceptable to allow such factors to also affect the processing of the picture data. For those operations the precise pixel coordinates entered by the user (when doing it by keyboard entry in Shift-C dialog, rather than by mouse) must always be accepted without any changes whatever, except for the obvious one of limiting the work rectangle to the current canvas size (which should always be done).

Edit:
Further experiments have proven that it is the current picture display scaling which determines whether selection coordinates as entered in numeric form by user will be modified or not, by methods similar to those used in scaling coordinates entered by mouse movements. Displaying a picture in 1:1 unscaled mode (Ctrl-H) will eliminate this unwanted coordinate 'rounding', but at cost of making it very hard to work with high-resolution pictures.

My conclusion remains unchanged:
IrfanView needs to be modified to accept user-entered selection coordinates without 'rounding' them either way, regardless of the current display scaling.

Best regards: dlanor

[Skippybox]

http://en.irfanview-forum.de/vb/showpost.php?p=19111&postcount=11

I agree, IrfanView should perform edits on actual image pixels and not screen pixels, when numerically defining regions. Obviously, this is not possible when working with the mouse, as you say. The best you can do is save your values in the custom selection box, and toggle the view to 100% then back when making edits. Not convenient, but that is just the way it is for now.

[Mij]

Displaying a picture in 1:1 unscaled mode (Ctrl-H) will eliminate this unwanted coordinate 'rounding', but at cost of making it very hard to work with high-resolution pictures.

Actually it is not so difficult working to pixel accuracy at high resolutions if you know a few of the dodges. My top tips are :-

1. In Options>Properties>Misc.1 uncheck Jump to next image if Page keys or Mouse wheel used .. That lets you use the Home, End, Page Up and Page Down keys to move quickly around the image. Much the best way of doing it.

2. In View>Display Options uncheck Use Resample for fitting... That lets you zoom right in to pixel level without it taking for ever.

3. After zooming the image turn on Irfanpaint (F12) and select the Arrow symbol (top left). Irfanpaint has much better registration between a selection box and the image.

4. If you want to draw a large selection box find the part of the image where you want the start corner to be and start dragging from there. Keep holding down the left mouse button as you use those Home, End, Page Up and Page Down keys to locate the part of the image where you want the end corner to be. Continue dragging the cursor towards that point and, magically, the end corner appears so that you can finish the box. Fine adjustment of the box is as usual by dragging the sides.

..perhaps someone else can contribute a few more.

[MItaly]

When I was writing IrfanPaint's own painting routine (that, as already pointed out, is quite precise in pixel positioning), I was also going to constrain the selection rectangle to the border of the pixels when redrawing the image, but I cannot do it while it's being resized. Do you think I should add a second "real" selection rectangle, maybe drawn with a different pen style? Something like the attachment:

[Bhikkhu Pesala]

I think, as long as it snapped to the true pixel boundaries on releasing the mouse it would be enough. Another pen outline might be confusing or just look like a bug.

[Skippybox]

As much as I agree with Bhikkhu, I have to say the guidelines would make placement very easy to visualize. I do like this "real" selection aid. But yes, it must be designed so users know what it is.

[Mij]

My vote would be with Bhikkhu too. I do not think guide lines are really needed in this instance.
I do think guidelines might prove useful in conjunction with some of the drawing tools in future and would prefer to see them reserved for that.

[dlanor]

My vote would be with Bhikkhu too. I do not think guide lines are really needed in this instance.
I do think guidelines might prove useful in conjunction with some of the drawing tools in future and would prefer to see them reserved for that.

I too think that there is little need of using guidelines only to illustrate to the user where the real pixel boundaries are.

Whenever a picture is so far zoomed that its individual pixels are clearly visible, like in that example, then it should also obvious where the boundaries of a selection rectangle will have to be rounded, either up or down so as to include all pixels 'touched' by the mouse-drawn rectangle. For that no visual guidelines should be needed, but merely a simple statement of how it works, somewhere in the help texts or other docs.


As for the other discussions of how mouse-drawn rectangles are treated, and the workarounds available, these have little to do with my original topic for this thread, which mainly concerned rectangle coordinates entered in numeric form, using the Shift-C command "Create custom crop selection..."

It is my impression that you all agree with me that IV should keep such user-entered coordinates unchanged (except for constraining them to canvas limits) and use those precise coordinates in all image processing involving the selection. (Whether the effect is to Copy, Paste, Crop, or whatever.)

But impressions alone are probably not enough to motivate the author of the program to recode anything, so please state whether you think this suggestion needs to be implemented, just like Skippybox did.

Since someone already has reported this issue earlier as an IV error (which I didn't know when making this thread), perhaps it even merits direct contact with the program author, to ensure that he's aware of it in preparing a future version.

I agree with the solution MItaly suggested in the other thread, of using true image coordinates for the selection box at all times. This should eliminate the problem completely, and the only case where a coordinate would be 'rounded' due to display scaling is when drawing the box with the mouse, since that must always act on the displayed picture. There are other ways to get around that too, but that is really a different topic, deserving a separate thread.

Best regards: dlanor

[Mij]

As for the other discussions of how mouse-drawn rectangles are treated, and the workarounds available, these have little to do with my original topic for this thread, which mainly concerned rectangle coordinates entered in numeric form, using the Shift-C command "Create custom crop selection..."

OK. It was a rather long original post that inevitably included several topics, but I accept that I was discussing pixel-perfect rectangles that are drawn rather than ones defined by the Custom selection box. It has been raised before and perhaps it is time it was referred to Irfan.

I don't of course know the full implications but on the face of it, it does not look that difficult. If you enter say 1000 and the closest line that can be drawn on the screen at current resolution is nearer to 1001, then clearly it has to be placed there but there is no obvious reason why the inverse calculation then has to be made to change the stored figure from 1000 to 1001. Clearly the displayed line is equally representative of either figure.
As soon as you drag any part of the box you do have to accept the inevitable imprecision, but if you make a crop or copy immediately after Applying the settings of Custom selection, I would agree that the figures you set should be what is used.