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.
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?
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?
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?
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).
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 ).
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 .
[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.
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”.
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.
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).
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.
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)?
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?
First, if you desire a feature then you should ask for it. However, it is unlikely that a new feature will be implemented unless you can convince developers that it is a good thing.
The problem with your feature request, as I see it, is that you have asked for a fundamental change in the definition of raster image formats. You also want to incorporate layout program features into an image editing program.
I understand what you want but my point is that you can achieve what you want by either (a) creating multiple different images from a single base image; (b) submitting a single larger image and letting the editor crop as he or she will; or (c) using a layout program that allows you to crop images to fit into frames.
[Sorry, Pat has replied while I was typing. I agree with you, Pat.]
I totally agree to keep the full resolution, that is the reason I wrote up this proposal. All it adds is a virtual crop that could be added anywhere in the process and changed later. It is a conveniance feature, nothing more.
Now I understand my mistake better, thanks! I failed to make clear that it is not a fundamental change of image formats but just a little addition, 4 xmp tags, not more. And I should have directly written to all the projects’ mailing lists. After my post to the darktable community I thought here would be the right place for further discussions since developers of at least some of the projects that I address are posting here and it is less formal than a direct feature request. And for a feature request some questions still would have to be answered first, such as “which xmp tags to use best”, another reason for chosing pixls.us, but wrong.
I still disagree on “incorporating layout features …”. I (and my feature) am somewhere between fine art (“never ever crop if you are not the artist”) and photojournalism/editorial photography (”don’t worry about the artist, he was already paid”). The initial crop should be respected but should be adjustable to some extent in my use case.
I think we understand? I would probably start by seeing which formats support virtual paging, and if they do, how (XMP sidecar? EXIF? Header?). I’d probably look into how Imagemagick currently does it, at least with PNG files? This could give you something solid to start with when poking the relevant projects…
There are quite a few folks here from various projects, so your request is not falling on deaf ears…
On a semi related note. A way to set the the focuspoint of the image would be nice as well. It would be usefull to do a bit of content-aware cropping for responsiveness websites.
@chris: Don’t feel bad for talking about your idea, I think it’s brilliant and it would have saved me quite some time already. I guess all those people not understanding it never used their photos in print where everything touching the page border gets hardware cropped (i.e., cut off), so you have to add a little image content to retain your original crop. Once darktable supports it in some way the most important part would be for Scribus to understand the XMP tags. Currently they seem to not read any XMP metadata, but that could be fixed.
Thanks, @houz, I already thought I was the “last man printing” . When I posted here I thought about a more “technical” discussion, since developers of several concerned projects are posting here (more on that later).
I understand that this feature is not for everybody but only for some people. Nevertheless, whenever I write up feature requests I carefully think about the cost-benefit ratio and in that case I’m pretty sure that it is not that bad.
I guess, since the need for this feature seems not that overwhelming, we should start on the scribus side with a little python script. There would be 2 possibilities to implement: Either it should import the image in a proper way or it should be run with an image frame selected and then properly zoom/place the image. I would opt for the latter, since it would not affect/change file handling and it could be run later (again). But I am not sure if access to the metadata of imported images is possible. The drawback would be that one would have to call the script explicitly for every image frame. I’m not sure if the script could be automatically triggered with every import of an image, but as a starting point I guess one could live without.
Still, the question of where to store the metadata has to be decided. The more I think about it, the less I like the idea of using the acr namespace. This information should not be tied to an oem namespace. If time permits today I will have a look at the hints that @patdavid gave (imagemagick/png).
).
.
I would probably start by seeing which formats support virtual paging, and if they do, how (XMP sidecar? EXIF? Header?). I’d probably look into how