I have now used PhotoLab 8 (latest patch) for some weeks and I must say I am very happy in general. But there is two bugs that annoys me:
I crop most of my images with 16x9 aspect ratio, to match my display ratio. After finished editing and cropping a number of NEF-files I select them and press the “Export to disk” to produce jpg-files. Many of the resulting jpg-files are then cropped with an aspect ratio that is not exactly 16x9. If I open the associated original NEF again in the PhotoLab-editor and press the Crop-button and then grabs the crop-edge to re-adjust I can see a small “jump” in the crop-frame when I start dragging it. Looks and feels like the crop was saved with wrong parameters/dimensions in the first place. Re-cropping and re-exporting to jpg usually get it right, but sometimes it fails in the same way even here so I need to re-crop even once again. This is rather annoying in the long term. Is this a known problem with PhotoLab 8? When can we expect a fix?
I run PhotoLab on a Windows 11 machine with 128 GB RAM. And I have always large amounts of free RAM even when running PhotoLab. If I let the PhotoLab-program minimized in the background and reuse the same instance to edit lots of NEF-images over time I see that the PhotoLab-process use more and more RAM (typically starting at about 4 GB) until it eventually crash (typically when hitting something like 25-30 GB) with a bang. It looks like DXO has some serious memory-leak problems with PhotoLab. Is this something being worked on? When PhotoLab crash I know that there is still plenty of free available RAM on my machine (typically more than 10-20 GB free). FYI, I have checked the Windows 11 option to “Automatically manage paging file size for all drives”.
16:9 and other odd ratios tend to be rounded to the next integer, unless you crop to something like exactly 1616x909 (integer multiples). Moreover, crop information is not stored as integers which can lead to inaccuracies, no matter how small.
3:4 is 0.750, while 4:3 is 1.333333333333333333333333333 etc. Although it’s the same ratio, one expression is precise, while the other isn’t.
The best way to get as close as possible is to drag corners instead of edges and adjust the position only when the ratio is what you want.
Like plenty of other applications I’ve used, PhotoLab has long had problems with garbage collection / memory leaks. I have the impression that it’s much better than it used to be. Still, leaving it running for several days will destabilize it. Only DxO can say if they’re working on the problem. I’ve had a hard time getting them to work on it, because it takes so much effort to reproduce any problems that occur. What makes this even more difficult is the possibility that a third-party component of PhotoLab is leaking memory (e.g., a DLL).
You mentioned that you crop most of your images with 16x9 aspect ratio, to match your display ratio. If you are exporting your PhotoLab images for viewing on a 4K video screen, you may be best off if you export to the exact 4K size (presumably 3840 x 2160 pixels). You may need to set up a new export to disk option for JPG at that size.
Let’s assume, for the moment, that you want a crop of exactly 3200x1800 pixels.
Do this:
set crop ratio to 16x9
drag the lower lefthand corner diagonally, until the short side is at 1800. Chances are, that the longer side is not exactly 3200 due to floating point calculations and rounding.
drag the lower righthand corner diagonally until the long side is at 3200. Chances are, that the short side will stay at 1800.
Now, drag the whole frame around until the crop frame surrounds the part of the image you want to keep, then hit ENTER.
Please note that
dragging sides instead of corners makes it harder to match pixel dimensions exactly and that is why it’s good practice to drag corners instead.
exporting to 16x9 can still change output dimensions due to floating point calculations and rounding.
setting the short side to e.g. 1802 pixels can never get you an exact 16x9 ratio. For an exact ratio, pixel dimensions need to be integer (1, 2, 3, 4…) multiples of 16 and 9 respectively.
I tried it but it’s impossible to get an accuracy that way with an image set to screen wide. I had to zoom in 500% to get a difference of 1 pixel when adjusting. I don’t think dragging the edge or the side does make any difference, both sides are changed. @leifel didn’t mention how much the size was off the ratio. But to get the exact ratio the longest size must be a multiple of 9x16=144. But when resizing somewhere later one will get the same rounding errors.
An image cropped to 9 by 16 pixels still has that 9:16 ratio
yes. There is a workaround though: export for resizing, crop, export at 100%.
For everyday use, it does not really matter (imo) if the image will be 1600 x 903 instead of 900. Nevertheless, there might be circumstances that require exact pixel dimensions, in which case I’d not use PhotoLab
I’ve just been playing with the 16 x 9 crop and experimenting with two different images (3x2 and 4x3).
In one case PL 8 showed the exact ratio of 16 x 9 in pixels, in the other case almost (presumably with rounding errors).
But when exporting to the 1920 pixel long side (for example) both came out at exactly 1920x1080 ( = cross-checked in PS ) … which is probably what @leifel is looking for.
Regarding the crop-problem, I understand the 16:9 mentioned rounding/integer explanations, but what I experience is at a much, much larger degree. I am talking about Nikon Z6iii images with original size of 6048x4032 that I try to crop to sizes like e.g. 5648x3177 (crop factor=1.78 or 16:9) but relatively often ends up with a size like for example 5602x3177 (crop factor=1.76) instead. Sometimes the result is even more “off”. This is not something that can be explained by pixel-level rounding errors, except if the cropping is done when the image is zoomed very far out but in that case I still believe the software should tackle it and perform the math so the result get the exact crop factor anyway (I am a professional programmer myself). I should not need to zoom in the image to a 100% (or close to 100%) view before I crop. I guess it is probably somewhere here there might be a bug in PhotoLab 8.5.
Note: When I crop I use the predefined 16x9-item in the Aspect ratio drop-list:
I expect this to give me an exact crop-factor as selected, regardless of how I drag the crop-selector frame, and the zoom-factor of my image on screen when I do the cropping.
Guess I need to bring it to DxO support level, as for the memory-leak problems.
If your preset contains optical corrections, than the original image might have been cropped, even with a factor larger then 1. Maybe you should take that in account too.
Made a few virtual copies with different distortion correction settings (constrain/unconstrained), cropped them with specific dimensions to 16:9 and exported to full scale JPEG and reduced size JPEG and - voilà - aspect ratios change.
Check the dimensions above the individual images. The ones at left still are 16:9, the others are not.
For the time being, it means that images have to be cropped individually in order to keep the intended aspect ratio. Cropping them all at once leads to shifted ratios which means that the crop is applied before distortion correction…which will preserve the image inside of the crop frame at the cost of a ratio gone off. I tend to see this as an unfortunate design decision - after all, we select a crop ratio because we want or need it for whatever reasons. The current implementation denies user intent and ease of use in this area.
@StevenL , can you check this with your colleagues? The current implementation is more of a UX issue than a bug (imo). Thanks!
These are based on the optics module. Both of these are perfect 1.5:1 ratios.
But, if I change the ratio to 16x9 and ensure that the long side is from edge to edge, then I actually get a long edge dimension of 6049 and a short edge of 3403, which gives a ratio of 1,777549221275:1 instead of the exact ratio for 16x9 of 1,777777777778:1 (which is more than likely actually 1.7 recurring, rounded for the last digit shown).
So, here you can see the non-integer problem that has been talked about by @platypus. And there really is no way around this unless you can set the pixel sizes to exact multiples of 16 and 9 at the same time.
Certainly dragging handles is never going to be a perfect solution unless you perfect the resize at a 1:1 zoom. And, even then, because mouse and screen coordinates are recorded as floating point values, there is still no absolute guarantee of “perfection” without rounding errors.
I am sorry @leifel but what you are requesting is mathematically impossible for the vast majority of mouse drawn 16x9 ratio rectangles.
This is not a bug with PL. I don’t know why you think you need such precision but, if it part of batch process with images of different cropped sizes, your only solution is to crop to a slightly larger size and use dedicated layout software to trim any excess.
I use optical corrections on all my images, and with the 24-120mm zoom I guess the implicit cropping that comes from this might be quite significantly different between pictures taken at 24mm and 120mm. When thinking through it, I have seen this problem only when working with images taken with zoom lenses and never when working with pictures from lenses with fixed focal length. It is also true that I have set the 16x9 crop in my preset. So this is probably the root cause.
I will remove the pre-crop from my preset and rather crop manually afterward and see if that makes this problem disappear. I guess so.
