Skip navigation
Currently Being Moderated

LR 5 - Image Sizing Dimensions - wrong image size

Jul 24, 2013 11:32 AM

Hi,

 

Image Sizing Dimensions produces wrong image sizes upon export for certain images.

 

Example, I have export set up for iPad resolution, 2048x1536px at 264ppi. If I now export an 3264x4928px image it should be resized to 1356x2048px. What I get is 1356x2047 instead, one pixel too short on the long side. This doesn't happen for all images source resolutions and ratios though. I haven't figured out the pattern yet.

 

Here a link to an image which exports at wrong size (export dimension set to 2048x1536px).

 

http://www.bobtronic.com/files/IMG_0289.JPG

 

I would appreciate a speedy fix for this problem. Thanks

 

cheers,

Matthias

 
Replies
  • Currently Being Moderated
    Jul 24, 2013 12:12 PM   in reply to Matthias Bober

    2048x1536 is a 4:3 ratio

     

    4928x3264 is not a 4:3 ratio, in fact it is close to (but not exactly) a 3:2 ratio

     

    Thus, when you say that you expect your 4928x3264 to show up as 2048x1356 (is this a typo?), this can't happen as the original is nearly 3:2 and not close to the desired 4:3 ratio.

     

    If you meant that you want your 4928x3264 to show up as 2048x1536 (is this the correction of the typo?), you are expecting a photo that is nearly 3:2 to be exported as 4:3, which can't happen.

     

    So ... the problem is at your end. If you want an export to have a 4:3 ratio, it MUST be first cropped to 4:3, which apparently has not been done.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2013 12:55 PM   in reply to Matthias Bober

    Nothing in Image Sizing will change aspect ratio.

     

    All of your examples do not produce a 4:3 aspect ratio because the photo you are starting with (4928x3264) is not 4:3.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2013 1:17 PM   in reply to Matthias Bober

    I guess we'll just have to disagree. 

    I don't want my image 3:2 image to become 4:3.

    Your initial example (the only one you have presented) does indeed start with a 3:2 image and you are claiming you want it to be 4:3

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2013 1:30 PM   in reply to dj_paige

    Hi,

     

    I'm not a LR expert so I could well be wrong but I have just noticed something in the figures that were originally quoted.

     

    If you start off with a 4928 x 3264 image and want to resize it to 1356 on the short side, according to my caluculation the long side would be reduced to 2047.29 [calc short side = 4928 * 1356 / 3264]

     

    LR probably can't make up anothe pixel.

     

    As far as I thought, the sizes you quote in the eport settings is actually the maximum size and not the absolute size. I believe you can als specify whether to size according to the short or long side.

     

    Could this have any bearing on the problem?

     

    Brian

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2013 3:10 PM   in reply to Matthias Bober

    This an absolute non problem. The answer is to do the processing properly, the way LR is designed to do it. If you want a image that is 1356x2048, which is 1:1.51, create a custom crop with that aspect ratio and crop your master. Then type in one or both of the desired dimensions in the Resize dialog. Granted this will cost you a few more seconds and few more finger flexes, but a problem that is so easily solved is not worth a rant.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 28, 2013 2:52 AM   in reply to Matthias Bober

    Hi Matthias,

     

    I did a little testing and indeed found that if you specify 2048, you end up with 2047. If you specify 2047 you get 2047 and if you specify 2049 you get 2049.

     

    I also found out that if you reduce the short side of the image by 1 pixel to 3263 x 4928 you get 1356 x 2048

     

    So there must be something slightly odd about your original aspect ratio that causes the problem. I suspect rounding down in the calculation somewhere.

     

    I'm not really sure whether the missing pixel would cause a problem on the ipad since it would be about .004 inch - but then my eyes are getting old.

     

    Brian

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 28, 2013 9:21 AM   in reply to Matthias Bober

    It works fine in LR4.4.1 and Photoshop CS6.

     

    4928x3264 Export Resize Long Edge 2048 outputs a 2048x1356 file.

     

    I suggest reporting this at the Bug Reporting site under 'Report a problem:'

     

    http://feedback.photoshop.com/photoshop_family

     

    LR4.4.1 Results

    3264x4928 Export Long Edge 2048.jpg

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 28, 2013 9:30 AM   in reply to trshaner

    Looks like Rob Cole already reported this issue with LR5 a month ago. I suggest adding your +1 vote and comments since Adobe still has not 'Acknowledged this as a problem:

     

    http://feedback.photoshop.com/photoshop_family/topics/lightroom_5_expo rt_isnt_resizing_exactly_to_specified_long_edge

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 18, 2013 6:34 AM   in reply to Matthias Bober

    That's definately a problem of missing quality assurance at the developing department. In a normal software development company there exist test cases that need to be run through bevor releasing a software. Adobe releases a "release candidate" and let the users do the testing. Unbelivable.

     

    I call this banana software. It mellows at the customer!

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 18, 2013 4:00 PM   in reply to Bert Nase

    It seems this issue was fixed in Lr5.2 (final release). Does anybody have reason to belief this issue is not so fixed in all cases, when using the final release of Lr5.2 I mean?

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 12:47 AM   in reply to Bert Nase

    Bert Nase wrote:

     

    That's definately a problem of missing quality assurance at the developing department.

    This problem was reported by the quality assurance department (users) before the product was released. You want my theory? - there's a bug in the bug fixing department...

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 2:40 AM   in reply to Matthias Bober

    Matthias Bober wrote:

     

    Unfortunatly Dimension resizing still exhibits the "one pixel too short" problem. Long Edge resizing on the other hand works fine now.

    I can't reproduce this problem. If I could reproduce it, then I may be able to add a fix to Exportant plugin so people don't have to change their export presets.

     

    Would somebody please post an image which when exported exhibits the malady, together with a sample export preset or at least the critical settings. - thanks.

     

    R

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 4:42 AM   in reply to Matthias Bober

    Thanks Matthias,

     

    Exportant v1.16+ should fix y'all right up :

    exportant_prevent_short_dimensions.gif

    Please let me know if there are any cases that aren't properly corrected by this option - thanks.

     

    Rob

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 12:23 PM   in reply to Matthias Bober

     

    The image has a resolution of 3264x4928. Exporting using Dimension resizing of 2048x1536 results in an 2047x1536 image.

    The scaling factor 4928 down to 2048, is 0.4155844155844156...

     

    Assuming that LR is working to only 3 decimal places here, which indications discussed in another thread would suggest, then there are several ways to achieve that:

     

    • truncate down to 0.415 by discarding the subsequent digits
    • "quick-rounding" of the third digit by inspecting the fourth-place digit only, and incrementing the third-place digit when the fourth-place digit is larger than 5, which it is not in this case, resulting in 0.415
    • "math-rounding" by inspecting all of the following digit pairs in turn, until you reach a pair that is lower than 50, and then working back again to simplify. This procedure rounds 0.41558 up to 0.4156, then after doing that, rounds 0,4156 up to 0.416

     

    Speculation: the difference between 0.415 and 0.416, is the difference between a result with 2047, and one with 2048, when executed.

     

    Most of the time the "quick-round" procedure will work out fine, also truncating will usually be good enough, assuming the above has anything to do with the reality (which it may not). Just occasionally, though, there'll be an error in the final digit, compared with what the theoretically accurate procedure would have given. So if I am right this is not strictly speaking a bug (something failing to execute as it has been designed to do), but the result of a software design choice. "Works as designed", iow .

     

    It seems that LR, perhaps differently between versions, is working this through by simple calculation (from the front-end), without comparing the back-end outcome against what you have requested. How much this (intermittent) issue actually matters, is a question of judgement, and of particular requirement.

     

    [ alternative method: I find the Print module, outputting to JPG, is completely reliable when it comes to making a standardised JPG as to the dimensions, as well as offering some different technical and design options, than what you get with Export. For one thing, you get the option of on-the-fly cropping to shape, which you can then adjust interactively where (as here) the image is a different aspect than the Retina display. So if you want it, you can fill the screen instead of getting letterbox, all without having altered your main (Develop) crop for that image. Alternatively, if you don't want the Zoom to Fill option (e.g. with landscape images to be shown in portrait orientation as part of a sequence) you can still make all your images to the same dimension, but controlling the appearance of the borders that are left (which become part of the image) ]

     

    RP

     

    ps: AFAICT one would expect simple truncation to produce the appropriate answer half of the time; one would expect simple rounding to just one further digit, to be wrong half of the times when the following digit happened to be 5 - or to put in another way, to be right in 95% of cases; and proper rounding, examinng as many places as it takes, to be right 100% (within precision limits).

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 4:48 PM   in reply to Matthias Bober

    Matthias Bober wrote:

     

    Something must have changed

    Yeah, they broke it. Which would be just fine with me (we all make mistakes) if they just fixed it in the next dot rev. Dunno why it takes 'em months or years to fix things that seem like they should only take days or weeks.

     

    Reminder: Exportant will fix the problem. If you don't like using plugins, then you can fix the problem without a plugin by manually editing your export preset files and adding a decimal fudge factor to the width/height values.

     

    Rob

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 6:19 PM   in reply to Matthias Bober

    Hi Matthhias,

     

    This problem was reported several months ago during Lr5 beta, and @Lr5.2 is still is not fixed.

     

    To be clear: Exportant can be used with publishing services, and will solve the problem immediately.

     

    Obviously it's your call, but I wouldn't wait on Adobe if it really matters to you..

     

    UPDATE:

    -----------

    If you are a plugin avoider, you can fix manually by:

    * Exiting Lightroom.

    * Loading preferences into text editor.

    * Changing AgPublish_size_maxWidth and AgPublish_size_maxHeight values in your publish service settings (e.g. add .1).

    * Restart Lightroom.

    (You may need to back those changes out if/when problem fixed by Adobe, but you may not).

    -----------

     

    ~R.

     

    Message was UPDATED by: Rob Cole

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 19, 2013 7:34 PM   in reply to richardplondon

    richard,

     

    that was a masterfull explanation of basic rounding - I knew quite a bit less about the subject before this and am fortunate to have been able to read your message.

     

    thanks,

    vince

     

    corrected typo

     

    Message was edited by: vinsolo

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 20, 2013 12:52 AM   in reply to vinsolo

    not very "masterful" considering it's wrong - it should not be "until you reach a number pair less than 50, but, "until you reach a single digit that isn't 5". The chances of even needing to go to these further decimal places are increasingly remote - 10% of 10% of 10% etc  - and, in any case, whether LR does then round this third decimal place or not, will only make any practical difference to the result, in certain borderline cases. And the smaller your output dimensions, the rarer such borderline cases will be.

     

    Personally, I am typically either making quite reduced standard output for web etc - 1680 x 1200 at most - or else just exporting at original resolution, where the actual pixel numbers are mere accidents arising from the LR crop.

     

    In this context, LR's precision is of no concern whatsoever.

     

    Even if I did get 1679 instead of 1680 ... which I don't recall ever noticing BTW... real-world evaluation: 'no biggie'.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points