P: Crop to specific pixel dimensions

[S360]

Its well documented that you cannot crop to specific pixel dimensions and many people have asked this very question. Just google "crop specific dimensions in Lightroom" Heck even someone has built a plug-in to solve the issue.

Do you want this feature? We do.

[areohbee]

I built the plugin (XmpCrop - free), and I'd love to retire it.

It's better than nothing for a lot of people, but it's klunky (uses xmp modification, since crop settings not supported by SDK)

This needs to be a native feature.

At a minimum (if not willing to make it a native feature soon), consider allowing plugin access to crop settings, so at least it can be made less klunky - ditto for orientation - hopefully develop settings support can be made 100% complete.

Rob

[ssprengel]

Crop is a ratio specified in Develop, and pixel Dimensions are specified in Export sizing.

Are you asking for a Crop parameters to dictate Export parameters, or are you asking for larger numbers to be allowed in the Custom crop dimensions and not have them simplified down to the smallest equivalent ratio so the math isn't so hard?

For example my monitor is 1680x1050 but Crop doesn't allow those large numbers, so I just use a custom entry of 168x105 as the equivalent ratio and it works fine as long as I also specify 1680x1680 in my Export sizing.

[S360]

Steve,

In our example take a src img from D800 7360x4912. Attempt to export image to 1601x1149 you will get 1601x1144.

[ssprengel]

What is your crop ratio, then? If my math is correct, using Original as the crop ratio would resize down to 1601x1068-ish.

In any case, are you asking for Export to not preserve the aspect ratio of the crop but resize by different factors in the horizontal or vertical dimensions if need be to exactly match the Export pixel dimensions specified?

[S360]

they simply need to match the pixels dimensions i specify not a ratio.

[ssprengel]

Pixel dimensions are a ratio, too, so if "they" could enter 1601x1149 as a pixel ratio for the crop and then the same numbers for the Export and the images actually came out exactly those dimensions then you'd be happy, right?

[areohbee]

You're close, and that much would be a big step in the right direction, but it would also be beneficial for crop dimensions to be interpreted as an actual number of pixels, for times when you really want to assure no resizing upon export, or exact halfing..

[ssprengel]

It seems like two changes would be necessary:

1) Allow larger crop numbers to be entered so you could enter the pixel dimensions as the crop ratio and not worry about determining a greatest common factor to divide both by if there is one.

2) Resize Exactly option rather than the Fit that always happens now so the off-by-one errors wouldn't occur due to rounding.

Those two would be enough if someone was careful to replicate the crop-ratio numbers into the Export Dimension numbers, but a third change, which is more as a convenience, would be:

3) Use Crop numbers as Pixel Dimensions as a specification in the Export panel.

This 3rd option could imply the 2nd but sometimes you might want 2) as a separate option that has nothing to do with using the crop numbers, just using exact numbers not tied to the aspect ratio. This would allow anamorphic resizing, too, so I'd vote to include 2) as a distinct Export parameter even if some other options forced it to be on.

The third option would also allow for different sizes of images to be output in the same Export run, since replicating Crop dimensions to Export sizing wouldn't require the same set of dimensions be specified like happens now.
--
As far as Adobe doing any of these, I could see their counter argument to be that someone wanting precise pixel dimensions not even off by one is likely not a photographer but someone doing web design or desktop publishing or maybe video work and therefore should be paying for at least Photoshop that has many more sizing options in the Image / Size panel so can easily do what is being requested. In other words we (Adobe) already have tools that accommodate these wishes and they aren't that common for basic photography processing so why should be add them for our discounted photographer-centric Lightroom product when we want them to sign up for the half-price LR+PS $10/month subscription. In other words, don't hold your breath, or at least tell why you want to be able to specify precise dimensions so Adobe can judge the photographer-ness of the request. Everyone who is not a photographer they want to pay the $50/month full-suite subscription price that is for businesses to pay, not photographers that are just scraping by and need a discount.

I do agree that Crop numbers should be part of the properties available to plug-in SDK, at least readonly so you could translate them to Export dimensions, but also perhaps settable so you could correct for off-by-one errors by tweaking the crop of the image being sent to the Export step on the fly, without having to resort to ImageMagick or a PS Droplet or similar post-processing steps.

[areohbee]

Crop numbers are already available to plugin read-only, they need to be writable.

[ssprengel]

I don't write LR plug-ins, and you do, so I'm asking: if the Develop Crop properties were writable in the plug-in, would changing them replicate those changes to the database, or just temporarily in an in-memory object that doesn't not replicate changes back to the database?

In other words, I can imagine that because Export doesn't change crop dimensions, an Export plug-in also wouldn't be able to change them, because that would effectively make it a Develop plug-in, at least If changes to those are updated into the database.

[areohbee]

Plugins need to be able to write crop settings to catalog, just like they can for almost all other develop settings.

I mean, if Lightroom supported exact cropping, both aspect ratio and dimensions, then there would be scant need for the XmpCrop plugin (which is a surprisingly popular plugin - a testament to the need for precise cropping in Lightroom).

Having writable cropping available to plugins would still be worthwhile, not anymore for basic cropping support, but for things like auto-import/auto-crop/auto-export, which is another thing a surprising number of Lr users want to do. It would also be good for things like restoring saved develop settings, and lots of other things ..........

Fingers crossed for Adobe to fill this hole in Lr6..

[areohbee]

The ability to define develop enhancements (e.g. crop) to be applied at export time (and NOT written back to catalog) is also desirable, but is not the subject of this thread..

[FeedbackCommunityMember]

I have found a way to crop without resizing to a specific pixel dimension. It does require to create a blank image using another program, to cajole LightRoom into making the crop the size you want! I've posted a video showing how to do it on YouTube. Am I seriously the first person in the world to do this??? That would be nuts... Anyway, check out the video. https://www.youtube.com/watch?v=4wsoS...

[JonPainterPhoto]

I'm a bit late to the discussion, but holy crap I could use this feature. Let's say I shoot a time-lapse on a camera that takes a 5760 x 3840 image. I want to punch in on a 1920 x 1080 pixel section of my frame and then I want to sync that crop with 1000 images. Sure Lightroom lets me use a 16x9 aspect ratio, but I don't want to go past 1:1.

[JonPainterPhoto]

You might ask yourself why I'm doing it this way, instead of using After Effects to create the timelapse and punch in. There's a reason. My client wants a date and timecode stamp, and the best way that I've figured out to do that is to:
1)import and process in lightroom
2)export the frames
3)run the frames through EasyBatchPhoto to timestamp each file
4)assemble the timestamped frames in AE.

Yes I'm beating my head against the wall. I spent a fair amount of time trying to figure out how to accomplish the timecode stamp in an adobe product... the exif data should exist with the frames in AE, Lightroom sure has it, but I haven't found a way to place it on a frame and have control over the location of the timestamp.

[Rikk Flohr: Photography]

There is a Lightroom plugin called Mogrify you might want to look into.

[Rikk Flohr: Photography]

While there is no way to guarantee a crop will come out on the 1920x1080 pixels but...

In the Export dialog is a checkbox for Resize to Fit. If you don't check it, you should never go past 1:1.

If you do check it, you can specify the physical output size in pixels and check the Don't Enlarge-again, it should never go past 1:1

[S360]

I have a unneeded copy of Lightroom because of this lack of function if anyone is interested. "no way to guarantee a crop will come out on the 1920x1080 pixels but.." doesn't work.

[Rikk Flohr: Photography]

Dan, I guess I would like to better understand why this is necessary. You can crop to your desired aspect ratio and you can export to a specific pixel dimension. What about a Pixel-Dimension Crop is required? What gain are you seeing by doing this? I am asking-not be facetious-but rather to understand.

[S360]

Hi Rikk,

I'm a bit surprised why several people have said why is this necessary. Cropping to a specific pixel dimension should be a no brainer and "not to aspect ratio". It is in Photoshop and we use everyday. We bought LR with the understanding it would. There is no "gain" in doing this it just part of our process and it sounds like others need this as well. Back to my question many months ago how to crop an image to 1601x1149. No solution unless we use Robs plug-in

[Rikk Flohr: Photography]

Dan, it isn't a no-brainer. If it were, I wouldn't have asked the question.

My personal belief (not necessarily Adobe's) is that you crop for the image's strength first. You crop to fit a frame or container's aspect second (placeholder, photo paper dimensions, etc). Then output is to a size that is appropriate for reproduction (if necessary).

I used to crop as you wish to: in Photoshop, with specific (sometimes arbitrarily assigned) pixel dimensions. As a graphic designer for print and screen it was sometimes necessary - to fit a specific container. I often ended up with less-strong images because the image content wasn't dictating the crop. When I abandoned the Container-first strategy, and went to an Image-First approach, the work improved. I honestly can't remember the last time, I filled in the values in a Photoshop crop.

Again, these are just my personal beliefs.

If I could understand what was lacking about Lightroom's current cropping/image sizing upon output it might help. I consider Lightroom's method to be vastly superior to Photoshop's but I am always willing to listen.

[S360]

Each has his own needs and ours is different. The product doesn't work for our needs and a Image-First approach definitely would not work.good day.

[JonPainterPhoto]

Hi Rikk,
The issue in my case is the line between photography and video isn't clearly delineated like it was 10 years ago. I'm using the software for photography, and also for videography, because video is just 30 pictures a second (when I'm shooting time-lapse, I'm getting 300-1000 giant photos from the camera and making 1 or more smaller videos out of all that data)

Because I'm shooting time-lapse, I have 2 different problems that should be easily solvable by adobe, (or even easier, by letting plugin developers have access to more under the hood)

1) I need to put image data (date and time of exposure) into the image. I'd prefer to do this in AE or Premiere, but hey, in either case the data's all there, the functionality isn't. (and we're talking about a couple lines of code, build a function and make an accommodation in the guy, we aren't talking about redesigning anything from the ground up) I need this functionality because a client is making a creative choice. As I've researched possible ways to burn time into images, I've seen a lot of people that want to do the same thing for scientific research. So it's not just me, there's a lot of people that do time-lapse that are hacking it out to make it work, and it would be helpful if Adobe would throw someone on it for a couple weeks and add the functionality to their software.

2) I can shoot an event, in this case a bridge going up, and I can make 1 wide shot, and 3 tight shots with the same frame, giving myself 4 shots out of the work one camera is doing. Which saves me renting 3 additional cameras, 3 additional lenses, tripods, sandbags, rain covers... you get the idea. So It would be helpful to be able to batch process the frames in lightroom and know that my frame is 1920x1080 without having to measure on the screen (which is what I did last night) In this case, the coding is even easier! The software is already doing that math! I just need a box that lets me design the size. As I mentioned, I could do this in AE, but in this case I have to have it happen in Lightroom because I need to go to a 3rd party application to burn timecode into frames since Adobe hasn't figured out problem 1 above.

Hope that helps explain where my issue is coming from.
-Jon

[JonPainterPhoto]

guy = gui (autocorrect fail)

[S360]

One year ago this was a topic. Checking back in to see if there's any progress, nope! Just upgraded to LR 6 and still must use a convoluted workaround.