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

[rht (Robert Thorsby)]

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.]

[chris]

@patdavid

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 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.

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?

Exactly.

Now I even failed to close the discussion

[chris]

@rht

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.

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.

[patdavid]

@chris

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.

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…

[andabata (Kees Guequierre)]

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.

[houz]

@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.

[chris]

@houz

@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.

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.

@houz

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.

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).

[chris]

@andabata

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.

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).

[Tobias]

@patdavid

I would probably start by seeing which formats support virtual paging

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.

[chris]

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:

[Tobias]

Perhaps you can write a bugreport to Scribus. But how should it look in the UI?

[chris]

@Tobias

Perhaps you can write a bugreport to Scribus. But how should it look in the UI?

In the case of ORA an option such as “Ignore bounding box” besides the image scaling controls would be optimal, however, a script to “remove bounding box from image” and a complementing “restore bounding box for image” that toggle the visibility of out of canvas material within the picture frame would do the job. The script would have to scale the image and centre it so that one dimension of the “bounding box” touches the frame and the other dimension is smaller than the available space. For the rest, there are already controls to shift and scale the image. Not optimal in terms of usability but working. If I could ask for improvement, a mouse interaction way of shifting and scaling the image and a warning if the frame is not entirely filled by the picture would be nice to have.

I will consider to write a bug report independent of my original idea, because for ORA files this feature would be beneficial even without the rest. But first I have to dig through the imagemagick documentation a bit more to follow the suggestion of @patdavid.

[Tobias]

Just to have everything here in the discussion. This is the link to the darktable feature request:
http://redmine.darktable.org/issues/10729

And the link to the Scribus ORA loading code:

scribusproject/scribus/blob/0efb28d103a32ed3e09df765b10a9b4c62e89e3c/scribus/imagedataloaders/scimgdataloader_ora.cpp

[chris]

@chris

But first I have to dig through the imagemagick documentation a bit more to follow the suggestion of @patdavid.

I tried to get the necessary information from the imagemagick home page (Cutting and Bordering -- IM v6 Examples, Basic Usage -- IM v6 Examples) and the png format specification (PNG Specification: Chunk Specifications). What I found out:

• Imagemagick uses the “virtual page” concept together with the formats GIF and PNG
• PNG does itself not specify this concept, however, imagemagick uses special metadata fields that are understood partially by other software, e.g. GIMP seems to understand the offset data but not the virtual canvas size data.
• The PNG metadata system is different of the metadata systems of other image file formats. Many formats, including JPEG, understand Exif and IPTC. XMP could be added to all file formats. PNG uses its own standard.
• Within the PNG metadata, imagemagick writes the fields oFFs for the image contents offset to the virtual page border and vpAg for the virtual page size, both not specified in the PNG standard.
• It seems that the image content is cropped anyway, in that sense, the concept of imagemagick is the opposite of the proposed idea. Imagemagick fixes the position of the cropped image relative to the original image, while I want to store the crop position without actually cropping the image.

Since the PNG metadata format is solely useful for PNG, I think XMP tags would be the most promising candidate for the proposed metadata format. The metadata from imagemagick could be used, but at the moment it does not seem possible to have a canvas size smaller than the image size (but negative offsets seem possible). ORA is another possibility, but much more complex than what I had in mind.

[andabata (Kees Guequierre)]

@chris

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.

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).

To manually set the focus point. Focus point information of the camera isn’t always available usable (eg. when focus is slightly missed , or there are multile focuspoints from the camera. etc etc). Regarding content aware cropping. It’s a bit hit and miss. and thus not really usable imho. I’ve rewrote the one from @Jonas_Wagner in php to play with it. But in the end it just isn’t reliable enough.

[Jonas_Wagner]

[quote=“andabata, post:35, topic:525”]
But in the end it just isn’t reliable enough.
[/quote]To replace a human? No. To assist a human? Yes. To serve as a better default - maybe.

Regarding the actual topic, hugin does do cropping via meta data but it’s used the other way around, so they can store only parts of a panorama image without the rest but I guess the same mechanism could also be used the other way around.

For me personally it’s probably not something that I would use and I don’t think it would make a sane default. Exif rotation is creating enough trouble already.