Feature request/idea that concerns several programs/projects: Crop info in metadata instead of cropped image

Software
1

Hi all,

I thought it would be a good idea to start the general discussion about my idea here, because it involves several software projects such as darktable and other raw developers, gimp, inkscape, scribus etc.

The problem: When you are working with fix layouts such as photo books, greeting cards or whatsoever, you often have to fit your photographs to a given image frame with a fix aspect ratio. This may not suit the aspect ratio of your original image and therefore you have to crop the image. In many cases, this would lead e.g. to cutting away feet of the subjects in the photograph (or, worse, cutting away their heads). If it is a stock photo, you have, of course, no chance to change, but when buying stock art you can buy an image of the correct aspect ratio. If the photograph is your own, you may have cropped the image in postprocessing and there would be the opportunity to go back in your workflow and reprocess your image with another crop that adds material at the left and right side of the image instead of cropping away feet and head. This is a cumbersome process since you may have to adapt your crop in e.g. darktable, repeat retouching in gimp with the new picture and then insert it back into your scribus layout.

What if, from the beginning, darktable offers to write the crop parameters into the metadata of the output jpeg instead of performing the crop. Gimp and scribus could recognize this crop parameters and insert the picture with the intended crop but leaving the opportunity to add a little to the left and right of the picture instead of cropping the feet away to suit it to the picture frame.

Technically, inkscape could handle the imported picture as a rectangle filled with a pattern. The rectangle size and position would represent the crop and the pattern size would be that of the entire picture. Gimp could handle the crop as mask but remember during export that the crop parameters have to propagate into the exported jpeg’s metadata. I guess in scribus there are similar options (inkscape and scribus have to handle only the input part while gimp has to respect it on both ends.

The next question is how to store the crop information in metadata. http://photo.stackexchange.com/questions/43893/how-to-store-tilt-rotation-and-crop-information-in-metadata discusses suggests using the adobe camera raw namespace in XMP since in EXIF and IPTC this information is not provided and XMP is flexible enough to do it.

With this post I want to start discussion about the feature, its technical implementation and so on. I already started a thread on the darktable users mailing list (http://thread.gmane.org/gmane.comp.graphics.darktable.user/8307) and @houz from the darktable developers already promised to implement the feature in lua once the lua capabilities to do it are available (I guess with 2.0 or maybe a bit later). But this only makes sense if this information is used by other programs. Therefore I ask you for your opinion/ideas/suggestion/etc.?

Best regards

Chris

1 Like
2

I don’t get it why you need to crop the photo in darktable at all? You could simply:

  1. Edit the photo in darktable
  2. Export the photo in full size in darktable
  3. Edit the photo in full size in Gimp
  4. Crop the image with a frame in Scribus
1 Like
3

I agree.

If you’re processing for a use where you’ll crop later, then why not just crop later?

4

Hi chris!

I’ve actually already seen this type of behavior quite often when using
imagemagick. The crop operator in imagemagick will internally represent the
crop as relative to the full image ‘page’ dimensions while operating. In
particular see the sections on using ‘repage’ in imagemagick. When
exporting out of the imagemagick pipeline some formats do not accept the
page information from a crop (JPEG), while others do (GIF and PNG/MNG).

http://www.imagemagick.org/Usage/crop/#crop

I was actually testing some other unrelated things a year or so ago and I
was exporting PNG files from imagemagick where I did specify a crop, but
didn’t +repage the output before exporting. Opening those files in GIMP
prompted me about what I wanted to do with the offset information contained
in the file. So at least from a GIMP standpoint, it’s aware of offset
parameters on an image, and can offer the option of what you want to do
with it (I haven’t actually checked about adding that information from
within GIMP).

From within the imagemagick docs it appears that the offset information is
saved in the file metadata?

It does beg the question that others brought up, though. Why not simply
output in full-size and use the ability to specify a crop natively in the
layout software? This way you can use a ‘virtual’ crop in Scribus and will
be able to drag/resize/reposition within the context of the layout software?

5

There are several reasons, but eventually it is all about convenience. Cropping is part of the artistic process. The raw development (decisions about colour look etc.) depends on the crop. Usually, I decide about the crop very early. And using the picture may be months or years after raw development. Therefore, I need the crop in the database of darktable simply to remember my intentions back then. Having two copies in the database, one with and one without crop, is very inconvenient. And repeating the initial crop in scribus by comparing the result with the file in darktable is even more inconvenient. Most of the time I want to do comparatively little changes, e.g. fitting a 2:3 photograph into a 1:sqrt(2) frame.

Of course, there are different workflows for what I want to achieve, and if you are doing it for 5 pictures it makes almost no difference. But if you want to do a photo book with 80 pages and up to 4 pictures per page, it makes a difference. Think of wedding photographers that have to do this 2 times a week, for them every little convenience feature makes an even bigger difference.

Of course I can live without the feature or mimic part of it by using an output style that reverts the crop, but for me it sounds like a little change in terms of programming (disclaimer: I have only a very basic idea about programming, so I may be wrong) but a huge time saver in photo processing.

In the linked thread on the darktable mailing list I explain some more details/background.

6

Why not use exiftool to add the crop information into the metadata of your final uncropped image?

Exiftool is available for all platforms and can use sidecar files (ie, XMP) or you can load the information into many places in EXIF or IPTC spots (eg, comment or description). Since the information only has relevance to you, you can be quite cryptic with your metadata (eg, 1024x768+240+580 using the crop formula from ImageMagick).

Metadata can be added to a JPEG without lessening the quality of the image.

One caveat though. When adding metadata make sure that this is the last thing you do with the image because many applications strip “unwanted” metadata from the input image – you want to avoid a later process stripping out the additional metadata you inserted earlier.

I add metadata all the time before sending images off to clients.

Robert

7

I feel I did not explain my idea in a way that the benefit is understood. Maybe it is because I am not a native English speaker, who knows. What I talk about is a (more or less) new image file format that adds something to existing image file formats that is similar to the pdf page boxes concept. I will give you an example use case:

Consider the scribus layout below.

856×965 738 KB

You can see that the duck’s bill reaches into the page’s bleed. The original image may have allowed to add a little on the left so that one could now change the crop in a way that the end result (trimmed page) comes closer to the photographer’s intention. But now we have to cut the photograph in an unpleasant way.

Even if I do myself the photography and the page layout, I want to decide about the crop as early as possible. Usually, that leaves no space for minor corrections. With crop metadata understood by many programs would allow an extremely efficient workflow. Adding such an image in scribus may present something that comes already close to the ideal result but minor tweaking is still possible. If photographer and designer are different people, such a file format would make even more sense (to me).

If you think the idea further, one could come up with an image (metadata) format that lets the photographer define an ideal crop and a maximum and minimum crop he/she would be fine with. An example: For the following picture, the photographer wants definitely the branch on the left to not appear in the picture and the two grass blades on the right should definitely be inside the picture. A respective metadata format would allow the following:

1128×597 912 KB

Red means the minimal allowed crop and white the ideal crop. Green would be the real crop of the image in terms of throwing pixels away. It would leave the designer the opportunity to tailor the image to the layout while maintaining the artistic vision of the photographer. Even an almost square crop would be possible in this case (green as horizontal border and red as vertical border). I hope it is a bit more clear now.

Thanks for the hint, I will have a look and report back when/if I find something interesting/useful.

As I explained earlier, cropping is integral part of the raw development and cannot be separated. I would have to do the crop, revert the crop in darktable export and do a similar crop manually in scribus again. A cumbersome workflow that could be eased a lot by 4 numbers (coordinates) in the metadata if all the programs respect these 4 numbers.

I use exiftool for different purposes, but in this case the question is not how to add the metadata but how to make software aware of the metadata. First, I want to do the crop with a graphical frontend (I guess the reasons are quite obvious) and very early, that means in the raw developer (in my case darktable). When I do the crop the position information is already there, so it would be best to add the info in the darktable export. If @houz wouldn’t have been so kind to present the prospect of a darktable lua export solution, using exiftool to transfer the crop information from the raw’s xmp file to the exported jpeg with reverted crop would have been an option, but the discussion is for the remaining part of the process.

Best regards

Chris

8

As a photographer I get my photo colors, lightness and composition into the best shape they can be in before I send the image out into the world. Your argument could be made for each of those three aspects, so the next request would be why not export images with untouched colors so desktop publishers can adapt them to their article, why not stop fixing exposure and using curves and leave that to someone downstream, why not leave the noise because maybe one of thousands of people who view the photo wants to use it in an article where a little grain would be good, and eventually why not just abandon JPG in favor of raw with processing parameters embedded in the metadata or in a sidecar?

It just doesn’t work that way. As a photographer I want my images developed my way before I send them out into the world.

Your duck example works against your argument, because it shows a well-processed and well-cropped image which you just need to downscale proportionally from the lower-left corner towards the top-right corner to make it fit. I see no reason for cropping it at all.

So basically what you are asking for is a raw image with processing parameters, so that you can discard them and have your own go at it.

P.S. A friend publishes gardening magazines, and in their company the photographer operates the camera but doesn’t touch the raw files - these are sent to a guy whose only job is processing them, as he knows what processing works best with their printers, their paper, and their layout designer.

9

First, it is not about someone that stumbles upon my photo and wants to use is, it is about a well defined workflow that I use and that I wish to improve. I do e.g. individual Christmas calendars every year, at least 8 different ones, and they have an aspect ratio of 1:sqrt(2). Now I want to fit photos in that are already processed, but they have different aspect ratios. And for some of the photos some important parts range into the bleed and will eventually be cropped. For them I have to go back into darktable, adjust the crop, export again and bring the image back into the template. This is done for about 1/3 of all images, each calendar having 13 pages and doing 8 calendars means 35 times that process. Having the option to recrop in scribus/inkscape would alone for that be a huge time saver. Of course there are other workflows that work but I guess this one would be the fastest. If I shoot only for the print then I crop a bit more generous from the beginning but the photos may already be processed for another purpose. So for multiple target uses the metadata crop information would be extremely helpful for me. If nobody else can see this benefit, I forget about this idea (it seems like that is the case).

I should have mentioned that (for whatever reason) it has to be a borderless print of the image, so that it has to range into the bleed and part of it will be cropped during physical production. In my calendar example above all images have to be borderless to have a consistent design.

No, the crop is something special since you stumble upon that requirement that parts of pictures may have to reach into the bleed. Experienced photographers that shoot for magazine covers will in their shots always leave space for the headlines that are added on the page and leave at least a bit space around the subject so that the picture can be cropped in production (and e.g. no feet have to be cropped away). Check several magazine covers and you can observe that.

But I would guess that the colour look of images will be touched as well within catalogue and magazine production towards a more consistent overall appearance. But I can be wrong on the latter part. The difference is that you can change the colour look of a processed result image in tiff or even in jpeg format to some extent, but it is not possible to add parts that have been cropped away. If this crop happened in camera you have no chance to recover it, but if you did it in raw processing then you have the information there. My idea is about workflow speed-up, nothing else. What I want to achieve can be easily done in (at least in my case) a much slower workflow. That’s all. If it wasn’t something I anticipated as comparatively little and easy change (for me as someone with little programming experience) in the image format (adding 4 to 8 xmp tags) and the software (exporting resp. reading that information and changing an image’s handling), i would have never suggested that feature.

For me it would be of great help, but if you see no benefit for you, just forget about it.

I guess that there are different kinds of photography (or reason behind it), since what you write above is totally different. If the photography is just for artistic purposes, the photographer/artist doesn’t want that anything is changed. If you are shooting sports pictures for the soccer magazine, I guess you don’t care about the final crop that suited the picture into the magazine layout. The example you mention here is more of the latter case while your sentence above (“It just doesn’t work that way. As a photographer I want my images developed my way before I send them out into the world.”) it is more the former. And not everything is black and white only, I even guess the two cases I mentioned are both not exactly on one or the other end.

10

Chris, in one sentence, why don’t you just export your images from your raw developer without cropping, so you can import them into Scribus or any other program and crop them as desired in those programs?

11

Not that I’m saying your idea is wrong or invalid, as you’ve clearly made a case for it with your workflow, but I am curious about something…

Is this not a thing that normally gets handled in the DTP software (Scribus in your case)? That is, don’t you define an object (Image Frame) in Scribus, then load an image into it? At that point it seems you can freely translate and scale the image inside that frame. It seems like you’d want to make the image frame the 1/sqrt(2) aspect ratio for your layout, then just load the images into that?

1140×677 441 KB

The original image is here:

Imgur

I’m not sure, but I would imagine that you would normally want your images to be their full resolution just in case you wanted to adjust the crop in your DTP later for whatever reason (layout, etc). That way you don’t have to go back to your image editing application to re-export a new crop, you can simply translate/scale the existing image to the extents of your Image Frame?

12

Because initially (during raw development) I decide about a crop and I want to stay close to this crop. Of course I could try to approach this crop in scribus later by comparing with the original crop (this is my fallback plan). The software just could speed up my workflow if during image import in scribus there is already a close approximation (scribus could fit the image as close as possible to the original crop automatically).

13

Exactly. And with the metadata that I propose added, if understood by scribus, the picture frame could be initially filled with the closest possible approximation of the original crop with the possibility to change it later. That’s all. I’m pretty sure that I could have explained it much simpler :smile: ).

The photo editing may be weeks or months before actually using that image (my Christmas calendars may contain images from January ;-)). To repeat the same crop in scribus for 8×13 images is a lot of work, but if a close approximation is already considered by the application, it would be easy to just scale/shift these images where the approximation is not good enough. At least we would guarantee that no feet are cropped away unless intentionally :smiley:.

14

[quote=“chris, post:13, topic:525”]
To repeat the same crop in scribus for 8×13 images is a lot of work[/quote]

It sounds to me like this is the core of the trouble you’re having, and the best solution is to voice your troubles to the Scribus devs so that cropping an image in Scribus is as easy as in darktable or RawTherapee or GIMP, not to have the rest of the world adapt to the problem.

1 Like
15

As I see it, you wish to recrop on-the-fly. The only way I know of doing this is to save your image as a postscript file and then manipulate the Bounding Box parameters.

But, like the others, I question the wisdom of doing this arbitrarily or automatically. What you seek to achieve is not recropping but re-composing. Your original out-of-camera image may be (say) 2000x1500 which you originally crop, and recompose, to (say) 1500x1200+200+100 [for those unfamiliar with ImageMagick the “+200+100” are the X and Y offsets from the top left corner]. You then wish to be able to change one or more of those four measurements quickly and easily (on-the-fly).

I appreciate that editors and layout designers often/always butcher photos and other artwork. And I appreciate that the person doing the recropping/re-composing will probably be you. However, in my workflow for fine art and exhibition, changing any one of those four parameters constitutes a new or fresh image and I am very picky about the new dimensions. I would never consider simply shaving 100px off the right side to be an acceptable “quick fix”. :grinning:

16

I disagree, because as easy cropping in scribus will be, it is still a lot of work to do the actual crop again and verify that it is close to the crop that was initially intended. Even without the verification it simply is more work. It is even more work, since if I do not export cropped pictures anymore, even those that would have naturally fitted will have to be cropped again. We can have different opinion about the question if “my” feature and the time saved is worth the implementation, that’s perfectly OK, but it would save time, all the alternative workflows that have been suggested simply need more time.

17

That’s it, more or less, introduce a bounding box for jpeg/tiff/png images.

That’s it, exactly. Not only quickly and easily but also in another program than the one used for the initial processing. It would be perfectly OK if intermediate steps just ignore the crop metadata. Think of a portrait that you processed in darktable, you retouch in gimp and use in a layout in scribus. It is not necessary that gimp knows about how to handle the crop parameters as long as the metadata propagates to the exported image and scribus knows what to do with it. (That’s not the whole truth since if you crop the picture in gimp in that case, the metadata would be worthless. But you would not in this workflow, therefore it is more or less valid.)

That’s exactly what I wrote in an earlier message. For some cases (fine art printing) it is not useful at all, for others it may be (my example above was about shooting soccer games for a sports magazine).

18

That’s it, more or less, introduce a bounding box for jpeg/tiff/png images.

I think that bounding boxes are useful for vector images but raster images should be specific dimensions.

I do not see the point of redefining raster image formats when there are so many applications that can do what you want by recropping and re-composing the existing image.

Publication editors will do what they like anyway. I don’t see any point in making it easier for them by sending a deliberately larger image just so they can chop it up. I shall always submit the image as I want it to be shown.

19

I see that nobody here stands up and says that he has a similar workflow and therefore thinks that it would be a useful addition that is comparatively easy to implement. That’s perfectly OK. We can close the discussion here because I understood that you (not personally, anybody in this thread) do not have any use for this feature. I do understand that you do not have a similar workflow and therefore I will not find ally here concerning this feature. What I do not understand is that you do not see the benefit in my workflow. Did I explain it that bad? There are tons of reasons not to implement it such as “there are billions of more important features that come first” or “you are the only one with this workflow because we do not do christmas gift calendars or we do our calendars with a frame or we do have only landscapes in our calendars where we cannot crop feet away or our calendar printer allows every print format” or “your assessment of being easy to implement is wrong because of …”. But my impression from this thread is that I failed fundamentally to explain it in a way that others could follow or understand. Where exactly did I fail (I ask to learn and do better next time)?

1 Like
20

I thought the idea was certainly a valid (if strange to me) one!

I guess in my workflows if I’m going to be adding images to a layout, I’ll be using them within the context of an Image Frame (in Scribus for instance).

For instance, when I process images, I don’t every apply a final crop destructively to the edits that I may have made. I will usually crop an exported copy of my image for the intended purpose, but I make sure to always leave an uncropped version of my final result on disk. (Sometimes I may re-visit it later and consider a change to the crop for various reasons).

As such, I’ll work on the full resolution image while doing almost all of my processing. I find that this leaves me the most flexibility for using my images in other workflows later.

That’s not to say your request is bad, just that it’s far enough outside of my normal workflow to not see any benefit from it personally. I think many of us here would opt for keeping the full resolution of a processed image first, then laying it out in the context of whatever the DTP software/layout should be.

I would imagine that if an export format allows it, you could always define a crop and ask the software doing the crop to make it virtual, saving the parameters in the headers/exif/wherever they normally go? Like maybe a “Hard” or “Soft” crop option?