When cropping with the 1:1 ratio selected, dragging a side of the crop frame yields dimensions that are not always exactly 1:1. It seems they can be out by up to 2 pixels.
Dragging a corner always produces a perfect square. I suspect this may affect other aspect ratios as well, but it’s a lot harder to tell.
My guess is the dimension I am dragging is absolute and then the other dimension is calculated via the ratio and thus subject to compounded rounding errors.
Hello @zkarj,
sounds the same like Cropping tool: crop to exact dimensions (keyboard input).
I see it like @George…for me a accuracy for 1 or 2 pixels doesn’t make any sense, but maybe there is a case where its important?
In the other thread it was the fixed frame size, here it’s the ratio.
I couldn’t reproduce it. A ratio of 1:1 will start with the shortest site of the image. No calculation involved, no roundings. I presume.
George
in the other thread it is the ratio, too. it is mentioned several times and also contains screen shots.
The problem does not only occur with ratio 1:1 but also with all other ratios. It seems to be a common inaccuracy under both Windows and Mac.
The name of the thread was “Cropping tool: crop to exact dimensions(keyboard input)”.
That was where the discussion was about: dimensions, not ratio.
George
The exact dimensions mentioned in the other thread are the goal not the method. I have the same goal. In both cases this is done by dragging and in both cases we noted that the ratio is not respected when there is no need for rounding. In the other thread’s case, 1500 x 1000 should be intrinsic to the 3:2 ratio, but it was giving 1500x999 or 1500x1001. It is understandable if the width is set to 1501 that the other dimension cannot be 1000.6 and so will round, logically, to 1001. But 1500x1000 is an exact multiple of the 3:2 ratio — no rounding required.
In my case, a 1:1 ratio is a common denominator for any size and so there is never a need to round pixels. To reiterate, if I drag a corner it is always exactly 1:1. It is only if I drag a side that the error occurs.
Yes it matters because my intent is a square shot, and while for some use cases a pixel or two may not matter, in others it will.
For instance, when I export I do so at full size, whereafter an automated script uses ImageMagick to add watermarks and resize the image to fixed dimensions. Sometimes I want to crop as closely as I can, so I set the crop to my goal dimensions, which the ImageMagick tool will address by not needlessly scaling the image. If it’s off by a couple of pixels, then I am going to get a scaled image that will introduce distortion as it is forced back to the intended ratio. Sure, 2 pixels in a few thousand won’t be noticeable, but there’s no need for it to be anything other than exact.
The workaround (at least for 1:1, I haven’t tested 3:2) is to finish with a corner drag to properly square up the figures. But often it is more convenient (and why else would PL offer the option?) to drag a side so that the other dimension stays centred on its current size.
In short, it does not always honour the ratio when the crop size (should be) a whole multiple of that ratio. That’s a bug, and my history tells me it’s a rounding bug. Possibly not enough precision in the calculation of the “other” dimension.
So, you are saying that, in the context of a 1000 pixel cropped image, one or two pixels difference would be noticeable?
That’s only 0.1% and, without doubt, invisible to anyone with normal vision.
In any case, when cutting the matt board for a frame, either the aperture in the board will cover the edge of the printed area or the cut itself could be off by more than 0.1%
I’ve a D750. Non edited the size is 6016x4016. It’s a common 2x3 sensor. When you calculate it, it should be 6016x4011 rounded. When I use the crop tool the initial value is 6016x4016: the image size. Now you can make the further calculations. Going to 1500 on the longest site (1500/6016)*4016=1001 rounded.
The D700, also a 2x3 sensor measures 3872x2592. Also not 2x3 exactly. I mention the image pixels. The amount of sensor pixels is I think 2 more per site.
Now check your own sensor.
George
From a mathematical perspective I think we don’t need to argue. 2925x2923 is not equal to 1:1. Why would this not be a bug?
I understand the whole topic may not be worth the discussion for some of you because you don’t care. But if you don’t care about the topic, then why do you spend your valuable time on it? What is the downside of fixing this bug? I can’t think of any.
Why don’t we all invest our energy in improvement rather than finding excuses to keep bugs unaddressed?
Cropping is capturing a specific content from within the original picture. That’s the main and for me the only purpose to use a crop tool. If I want a specific size I do that afterwards.
But I’m interested how things work. So I don’t understand why you don’t get a square with even sites. I do get them, exactly the same. If you don’t get that equal result then there must be a reason.
Yes. It’s noticeable as soon as I see two numbers that are not equal when they should be. My point is not that it will always be noticeable in the output, but that in my workflow it can cause processing to be performed which a true 1:1 crop would avoid. Extra processing brings with it the possibility of image degradation and even if I didn’t process it beyond PL, I wouldn’t have a square image and I can certainly imagine a web upload function that demanded a square and got snippy when it wasn’t.
But regardless of whether you or I can see a difference in any given case…
I couldn’t have put it better myself.
Also, if 0.1% is not enough for concern, I managed to get it up to 0.38%. I have a piece of software on my Mac that accepts icons of 512 pixels in size and it will reject an image that is not perfectly square.
And finally, I think this is proof it’s a rounding problem. I struggled to get the error at the above dimensions, but as you drag larger you can see the numbers change further and further out of step. So I went big and managed to get a 3 pixel error.
Judging from your screen capture you have not done the one thing I described as the cause of the bug — drag a side of the crop rectangle. It looks like you’ve just gone into the crop tool and selected 1:1 and done no dragging (as it is showing full frame height). And to clarify again, it will not always be wrong, but as you drag it, for some of the time the numbers will not agree.
I have dragged the horizontal side, the vertical side and the corner, the numbers stay equal. So I can’t reproduce your problem. I tried different images from different camera’s. None of them gave problems, even sides all the time.
What was your starting point? The original image. Maybe you could post an image?
George
Sorry, I stand corrected. Maybe it is another Mac vs Windows thing? This happens all the time on my images. The one I did the above testing on is 4928x3264 and without any prior processing (other than default) I went straight to the crop tool, set 1:1, and started dragging. It doesn’t take many goes to see the problem over about 400 pixels. It gets commonly out by 1 over about 1000 pixels, and out by 2 around 2000 pixels.
Furthermore you can see the error even more easily while slowly dragging, as at very small dimensions the two numbers roll over in lock step. As you get to larger dimensions you can see them changing at different times, even if they ultimately land on a correct result. Describing this it occurs to me it may be to do with Mac Retina displays, where one screen pixel is not equal to one logical pixel (at the OS level). I think the Windows equivalent is display scaling (which in my experience at work is not terribly well executed even by Microsoft).
When I say it happens “all the time” I don’t use square crops on everything, but every time I do I notice this and have to drag a corner as the final action. I note that in my current project there are already 8 square crops so that will be why I noticed it enough to start this thread.
I’ve had this happening often, few pixel off one side. Quit often, resizing to 1200px long length, with the other should be 800px but I get 799 or 798px.
With the example of Zkarj, 4928x3264, you might get 1200x795.
I think PL and maybe every editor, starts with the 100% frame and calls it by it’s nominal size being 2x3. But the sensor size isn’t exactly 2x3, and the image sizes will be 2x2 pixels less when I’m right. And the other ratio’s are derived from these setting.
Leaves the 1x1 ratio as a different example.
George
it also happens under windows, PL versions 2.x and 3.x see this:
I don’t see how the original frame has any bearing on the crop ratio unless “original” is selected. In that case, sure, the original ratio may be off from a perfect 3:2 or 4:3, but when I select 3:2 explicitly (or indeed 1:1) the mathematics should not involve the original frame size except as an upper bound.
Also, if it was the original ratio informing the error, then it would not be possible to get an exact 3:2 or 1:1 crop at some sizes, but you can always achieve an exact ratio (rounded to whole pixels) simply by dragging a corner handle. For example, my square crops I target a final size of 2600x2600. If I drag by a side, I might get 2600x2601, but by dragging a corner out and back a little I can reliably get 2600x2600.
Hi folks,
only for my salvation 
I’ve made the same test George does.
First with 14% view setting a 1:1 crop and I can resize the frame by 7 pixels height and width identically
It is Win10 64-bit / DXO PL 3.2.0 4344
