iv: Flip and rotate should be added to the edit menu (or view?)

[lgritz]

originally #290

[soswow]

Currently there is no "edit" menu. Also, are there any function IV today that would changeimage in place? Since I don't see "Save" button in the code, that would have to be also added.

[lgritz]

I think there are no functions currently that alter the images. And therefore no need for save/save as.

If we allow for rotating, say, then I suppose it makes sense to bring that back, if we want people to not only be able to have it rotate for viewing within that session, but also to save the file with altered metadata about the desired orientation.

[vangeliq]

@lgritz I can try doing this.
The file menu already has a save as function, so I can add a "save" option. I'll add a new "edit" menu that has rotate and flip.

Question:

• Will the transformation be read/written to the metadata or are we manipulating the image pixels?
• Where can I find the list of file types that this feature will have to support (and be tested against)

Thanks!

[lgritz]

@lgritz I can try doing this. The file menu already has a save as
* Will the transformation be read/written to the metadata or are we manipulating the image pixels?

Good question! I think an argument can be made for either, but my instinct is that the easy and fast thing to do is just to manipulate the metadata. iv already recognizes the "Orientation" metadata and displays correctly, and I think that for other viewing programs (like Apple's Preview.app), "rotating" seems to just alter the metadata.

Let's do that for now. And once people start using it, we can see if there is a request to also rotate the pixels for real, and if there is, perhaps can also make a separate iv menu option that's the equivalent of our ImageBufAlgo::reorient() which moves the pixels to match the Orientation (and resets the Orientation to default).

* Where can I find the list of file types that this feature will have to support (and be tested against)

You mean to save? Or to rotate?

The beauty of OIIO as a "format agnostic" API means that it's the same sequence of calls to read or to write, no matter what format it is (just the filename changing is all you need). I don't think there's a need to "test" multiple formats. Just fine some JPEG file from your camera, that's good enough.

HOWEVER, there are two wrinkles!

1. Not all image formats that we read are supported for writing. So I think some provision will be needed to recognize when the "save" action is triggered for a file whose name corresponds to a format we don't have a writer for. (Maybe in that case, you can just have a pop-up dialog that says there is no ability to save that format, and recommend using "Save As" instead.)

2. Another consideration is particular to the rotate-as-orientation-change approach we discussed above. Not all the formats support storing the display orientation! I think for a first stab at it, maybe just sweep this problem under the rug and ignore it. We can come back to it later and decide how to handle that case. I think the most common case for wanting to rotate in the first place is for images that come from a digital camera, which detects how you're holding the camera and saves that in the Orientation metadata so viewers know how to display it (the cameras don't rotate the pixels, just set the metadata). But sometimes it doesn't save the orientation you really wanted and that's why you rotate in the viewer and want to save it out again. These are generally going to be JPEG images, which can save the orientation properly when written out again. (The other camera case is RAW images, but we don't write raw images anyway, so we can also forget about that for now.)

[vangeliq]

Thanks for the clarifications!

You mean to save? Or to rotate?

I meant the rotate. When I searched a bit about image formats I found that - as you mentioned - not all formats store the orientation metadata. I assumed we wanted it to work for all formats, hence why I asked about testing. But I'll ignore these for now and work on rotation via metadata, and then go from there.

[lgritz]

Once the file is read in, the attribute will be honored by iv when displaying, regardless of whether it was in the original file or added by the rotate command.

So the trick is what happens when we save, and the file type does not permit a display orientation of any sort. Let's just ignore this issue for now, and assume that if the user wants a changed attribute to save, they need to save to a file type that supports it. We can come back and find a more robust approach if it's a problem in practice. I think that in real life, it will be rare to want to rotate an image coming from a file type that doesn't support the idea (since, as I said, the main application is for camera images or scans that have saved an unintended rotation, and those formats would support the tag).