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.
1 Like
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)?
1 Like
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.
Exactly.
Now I even failed to close the discussion 
1 Like
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.
Thanks for making things more clear.
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.
1 Like
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).
Do you mean to manually set the focus point in the software or to use the focus point information from the camera. The latter would be of little help because of focus-and-recompose (at least it would not be very reliable). Besides this, there are plenty of content-aware automatic cropping solutions around, e.g. Introducing smartcrop.js - 29a.ch or facedetect: a simple face detector for batch processing (part of fgallery: a modern, minimalist javascript photo gallery).
I’ve done a test with Gimp an ORA (OpenRaster) does support a bounding box. Krita and MyPaint support ORA too. I don’t know about darktable but Scribus doesn’t support ORA in the version 1.4.4. But it should be relative easy to add ORA support to Scribus and darktable. ORA is simply XML+PNGs in a ZIP file.
Thanks for the hint, according to [scribus] Open Raster import in 1.5.0svn scribus can read OpenRaster images (I read about it on wikipedia’s OpenRaster article). It is not clear from the specification which file types are supported inside the ORA container (at least http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft/FileLayout/ is not very specific). OpenRaster sandbox suggests that JPEG is possible. I would guess it depends on the implementation which types are supported. Nevertheless, the ORA format may be a bit too sophisticated for what I want to achieve, but would definitely be a possible solution.
Of course, in that case on the scribus/inkscape/whatever side the right things have to be done with the ORA file. At least the crop coordinates must somehow be available within scripts or only a native implementation would solve the task. A quick test with a gimp generated ORA file with a layer size larger than canvas size shows in scribus 1.5.0 that the canvas size is hard cropped and even shifting the image around in the frame does not help. See the following screenshots.
Original image:
Image cropped by reducing the canvas size, maintaining the layer size:
Import into an image frame in scribus:
Shifting the image around in the frame:
Perhaps you can write a bugreport to Scribus. But how should it look in the UI?