improve interaction with external RAW editors
Submitted by an unknown user
Link to original bug (#717210)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-01-05 03:40:00 -0800 ----
Original Redmine bug id: 3061
Original URL: http://redmine.yorba.org/issues/3061
Searchable id: yorba-bug-3061
Original author: Ruth -
Original description:
possibly related to ticket #1772 (closed): If I edit a raw photo externally with the raw editor, then it creates a jpg file in the same directory. As it is now, this jpg photo will be displayed in shotwell next to the original raw version. I would like it to display only the jpg file.
I think this behaviour works already when 'open with external editor' is used, because then a file 'XXX_modified.jpg' is created, and that one is shown instead of the original.
I would like the same sort of thing to happen when 'open with raw editor' is selected.
Related issues:
- related to shotwell - Feature #1772 (closed): allow a single photo to contain a RAW+JPEG pair (Fixed)
- related to shotwell - Feature #6391: Multiple RAW development presets (Open)
- duplicated by shotwell - 4335: Use of external RAW editor saves in bad file format; resu... (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-01-17 12:23:00 -0800 ----
History
Comment 1
Updated by Jim Nelson almost 3 years ago
I'm not sure I follow. If you select “Open with External Editor†on a RAW file, it will create a _modified file, but it shouldn't display both it and the RAW file, only the _modified file (in place of the RAW file). Is that not happening for you? What version of Shotwell are you using?
Comment 2
Updated by Ruth - almost 3 years ago
yes, open with external editor works. But open with raw editor doesn't . I would like that to behave the same way.
I use rawtherapee as raw editor, I have tried to let it save the file as XXX_modified.jpg but shotwell still imports that as a new file.
I use shotwell 0.8
Comment 3
Updated by Adam Dingle almost 3 years ago
- Subject changed from keep jpg version combined with raw to keep jpg version combined with raw after external edit
This ticket is related to#1772(allow a single photo to contain a RAW+JPEG pair). Once we implement that, when the user edits an image using an external RAW editor and the external editor writes out a JPEG, it would be nice if the resulting JPEG could be associated with the original RAW image as suggested here.
Comment 4
Updated by Adam Dingle over 2 years ago
- Subject changed from keep jpg version combined with raw after external edit to improve interaction with external RAW editors
To make this work smoothly, we might need to have special-case code for various RAW editors because they might save photos in different ways. But that might still be worth doing (perhaps via a plugin interface). Some external editors might not even save JPEGs automatically, in which case we might need to ask them to render the image explicitly; see
http://lists.yorba.org/pipermail/shotwell/2011-February/001838.html
Comment 5
Updated by Adam Dingle over 2 years ago
- Target version set to 0.11
- Priority set to High
Comment 6
Updated by Eric Gregory over 2 years ago
See related ticket: #3730 (closed)
Comment 7
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.11_</strike>
)
Comment 8
Updated by Adam Dingle about 2 years ago
- Description updated (diff)
There's one more important case here: a user might have existing JPEG images which have already been generated from RAW images in the library using an external RAW editor. In this case, Shotwell will have no opportunity to observe the RAW editor being launched.
Since we've seen that may be difficult for Shotwell to automatically determine which JPEG images have been written by RAW editors, as a first step we could implement a command which allows the user to specify manually that an existing JPEG image is actually the external raw development of an existing RAW image. That would require an extra manual step, but would work in any case. If we take this approach, this feature will now look a lot like #4040 (combine/separate RAW+JPEG photos) with the difference that when the user merges a RAW and JPEG photos, they'd like the JPEG photo to be considered as an external development of the RAW image (whereas in #4040 it's a camera development). We should think hard about whether that distinction is even worth maintaining. As an alternative approach, we could implement some sort of photo stacking (#2090 (closed)) in which RAW and JPEG images can be grouped together but it's the user's reponsibility to know where they came from, exactly.
Comment 9
Updated by Martin Ling over 1 year ago
- Description updated (diff)
I am waiting impatiently for this feature, it's the only thing blocking me from using Shotwell at the moment. I am in the situation mentioned in comment #8 (closed): I have a library of 20,000+ photos processed with UFRaw that I would love to import - right now I have no solution for tagging, etc - but I need Shotwell to recognise these for what they are and also work correctly with new images that I process in UFRaw, otherwise it's not a usable solution for me.
Some information that might be useful: in some cases you may be able to read the Exif.Image.Software and/or Exif.Image.ProcessingSoftware tags to identify the developer of an image. Many raw editors will identify themselves in these tags. I know UFRaw writes this tag because I added that code myself a couple of years ago, and some searching suggests a lot of others do too including Adobe & Apple packages, digiKam, and rawstudio. Also those that don't could very easily have this feature added to help them interoperate with Shotwell, if their users request it.
In my case at least, it would be sufficient for Shotwell to treat any JPEG file, with the same filename as a corresponding raw image in the same directory, where the Exif.Image.ProcessingSoftware tag starts with 'UFRaw', as an externally-developed version of that raw image. This would work for both initial identification, and catching newly edited images that appear in a library directory. A simple list of tag patterns for matching known RAW editors would let this support other programs too, with new ones added easily.
This won't catch the cases where the externally developed version gets saved with a different filename, or in a different directory, but in many cases the user will be able to adapt their workflow to avoid doing that.
Catching every possible case would require fancy configuration of where raw and processed images get stored, or metadata/image based detection of probable edited duplicates, but both of those are separate features in their own right and aren't needed just to make this usable.
Comment 10
Updated by Eric Anderson 12 months ago
This is an issue that causes me a lot of trouble as well. With my particular camera, the "Camera" development option produces a low-resolution image, and the "Shotwell" option makes the colors painfully flat. Either way, the benefit of shooting in raw is almost completely lost. (I say almost, because the raw file is still there; it just means giving up the convenience of using Shotwell.)
It seems to me that the "right" behavior is about like this:
- "Open with raw editor" waits for the editor to terminate and then either (a) takes the file produced, or if that's not possible (b) gives the user a file-selection dialog to find it manually.
- Any (supported) raw editor should be an option for the "develop" menu, so that the editor is invoked automatically after the raw files are imported.
As far as I can tell, doing this intelligently requires special-casing the raw editors, and/or letting the user define command line and generated-JPEG- finding rules directly.
Am I out in left field here, or do the rest of you agree?
Comment 11
Updated by Moe Blue 12 months ago
Eric Anderson wrote:
This is an issue that causes me a lot of trouble as well. With my particular camera, the "Camera" development option produces a low-resolution image, and the "Shotwell" option makes the colors painfully flat. Either way, the benefit of shooting in raw is almost completely lost. (I say almost, because the raw file is still there; it just means giving up the convenience of using Shotwell.)
Eric, maybe shotwell recovers the embedded jpeg as the camera developed version. My workaround is to use Shotwell as default developer (which produces the flat color/dark image) and then switch to camera developer afterwards.
Eric Anderson wrote:
Am I out in left field here, or do the rest of you agree?
Using Camera-Developed JPEG is fine for me in 95 percent. However, it would be great to have better integration to other raw development tools such as ufraw or darktable. Btw, darktable has a new CLI, maybe that helps.
Comment 12
Updated by Jim Nelson 12 months ago
- Target version set to 0.14.0
Integrating the various RAW editors out there is a challenge and it may be that we have to use some of the suggestions you've made, Eric. I'm curious: how low is the resolution of the camera-developed image? Most RAW cameras embed full-sized (or near-full-sized) images in their RAW file.
We'd rather not wait for the RAW editor to finish, as that has a lot of problems on its own. What we do for "normal" external editing (i.e. GIMP editing a JPEG) is to monitor the file for changes and made that file the baseline for all future changes within Shotwell. That's a similar strategy we've elected for Shotwell with RAW development.
Comment 13
Updated by Jim Nelson 11 months ago
- Category set to library-mode
Comment 14
Updated by Jim Nelson 11 months ago
- Category changed from library-mode to raw
Comment 15
Updated by Jim Nelson 11 months ago
-
Target version deleted (
<strike>
_0.14.0_</strike>
)
Unfortunately, this is a big enough problem we're not going to be able to get this for 0.14.
Comment 16
Updated by Roumano - 10 months ago
Darktable (a raw developer) as just commit a dbus server to add a way to tell it to load images/folders.
Etherwise, it's can also be launch via command line
For more information, see
http://www.darktable.org/redmine/projects/darktable/repository/revisions/543e6 64f367721e88dfa0cddf5c93006adbc7576
It's will be great, if darktable can be added as external raw developer in shotwell
--- Bug imported by chaz@yorba.org 2013-11-25 21:49 UTC ---
This bug was previously known as bug 3061 at http://redmine.yorba.org/show_bug.cgi?id=3061
Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution