Re: ufraw (and others) integration
Ulf Rompe wrote: Am Sonntag, den 04.11.2007, 20:14 -0500 schrieb Daniel Falk: I'm wondering if this fits in with a workflow that doesn't want to keep the raws forever. I'm wondering this because that's the boat I'm in. I take way too many pictures and have too little hard drive capacity to keep the raws around, but the actual jpgs I'd like to keep. What would be the best way to do that? There just doesn't seem like a really good way to either a) import only jpgs or b) replace raws with jpgs after import. I could imagine a simple extension that gives you an additional menu item called something like Delete RAW versions of selected photos. Right now digging my way into F-Spot extension hacking, I would say such an extension would be easy to implement. [x] ulf That would be very good. Although currently I'm archiving the RAW's to DVD along with their sidecar files so that if I do want to go back and look at them later I can. I should have been more specific in my original posting. Could you suggest a solution to this? It could be as simple as instead of deleting the raws, moving them to a predefined directory where they can later be archived off to a disc. Thing is, I'm also not sure how the sidecar file (which I think is called *.ufraw in this case) is handled in f-spot, nor do I know if UFRaw allows those files to be moved around to different directory locations. ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
Am Sonntag, den 04.11.2007, 20:14 -0500 schrieb Daniel Falk: I'm wondering if this fits in with a workflow that doesn't want to keep the raws forever. I'm wondering this because that's the boat I'm in. I take way too many pictures and have too little hard drive capacity to keep the raws around, but the actual jpgs I'd like to keep. What would be the best way to do that? There just doesn't seem like a really good way to either a) import only jpgs or b) replace raws with jpgs after import. I could imagine a simple extension that gives you an additional menu item called something like Delete RAW versions of selected photos. Right now digging my way into F-Spot extension hacking, I would say such an extension would be easy to implement. [x] ulf -- A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station... ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
I'm wondering if this fits in with a workflow that doesn't want to keep the raws forever. I'm wondering this because that's the boat I'm in. I take way too many pictures and have too little hard drive capacity to keep the raws around, but the actual jpgs I'd like to keep. What would be the best way to do that? There just doesn't seem like a really good way to either a) import only jpgs or b) replace raws with jpgs after import. Am I missing something? Are there options I haven't considered? If not, how can this be accommodated? I'm fairly sure I'm not the only one in this situation. What do you all think about this? Thanks, Dan On Thu, 2007-09-06 at 11:12 +0200, Stephane Delcroix wrote: An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) - code for keeping Raw+Jpeg together at import time (will make the merge addin obsolete) will come after that hope it clarify the situations a bit... regards s On Tue, 2007-07-17 at 17:57 -0400, Peter Finley wrote: I looked into doing something similar a while ago. I dug around in the code a bit and if I remember right, I found that the biggest issue with this is that the database doesn't support versions of an image with different file type extensions. This means that a JPEG can't be stored as version of a RAW file. I couldn't think of a good solution that didn't involve changing the data model. It may have changed since I looked at it, though (I hope so). It was several months ago. Peter On 7/16/07, David Collett [EMAIL PROTECTED] wrote: Hi all, I've spent a bit of time searching the lists for where RAW support is currently at and where it is headed, but it's still unclear. What follows is a description of a simple workflow which I think would suit many people in the meantime, and should be easy to implement. My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. Ufraw can easily be told via the commandline, how and where to save the output file, suiting f-spot integration. Furthermore, Ufraw can optionally save an ID file which stores the settings used during raw conversion. If desired, this could be saved, so that if the photographer decides they dont quite like their conversion, they only have to right-click and develop again and will start where they left off in ufraw (the resulting jpeg would become yet another version). Batch processing can easily be accommodated too. Suppose you have a set of photos shot in the same conditions and want to batch process them. You can right-click/develop the first one as described above. What this will do is set your current adjustments into your .ufrawrc file (a standard ufraw feature). Now you can select all the remaining photos in the set, right-click and choose develop with UFRAW, when the develop action is invoked with multiple selections, it will launch ufraw-batch instead of ufraw (ufraw-batch comes standard with ufraw). Once the photographer has a good 'developed' jpeg image as a version, they can further edit it with the standard f-spot set of tools (or externally via gimp etc). This may not be the holy-grail of RAW integration in f-spot, but it would be a big step up for those of us currently using f-spot to manage RAW photos. Can other f-spot users let me know what they think of this approach? Can the developers let me know where I might start implementing it? I
Re: ufraw (and others) integration
Hi everyone, I'm liking the way things are going with RAW processing recently, I think I might be about to make a full switch back from digikam. Just a couple of issues I've noticed, Pentax's .pef and .dng extensions aren't in the IsRaw function so it won't shell out to ufraw. (src/Imaging/ImageFile.cs line 218). I'm guessing there are probably a few other ufraw supported RAW filetypes missing? Also, I think raw.Uri should be escaped when shelling out to ufraw so that if a picture name has special characters, or someone opts to not copy files when importing the call to ufraw will still work. (extensions/DevelopInUFraw/DevelopInUFRaw.cs, line 35 perhaps?) The PEF RAW thumbnails are not displayed in the main browser, though the DNG files are. From a quick look at the source it looks like this is handled by the gnome libs, so I guess once I upgrade gnome it might start working? It's interesting that they work fine in nautilus though... It'd be nice to have f-spot not block when calling ufraw with this extension, so you could still look at your other photos while developing to compare, but I guess that would be pretty tricky currently. Cheers, Tim. ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
I just discovered svn diff, lots easier than diff -u.
The attached diff simply adds Pentax RAW file extensions to the list
in the IsRaw function.
I'm had a slow time compiling and installing the DevelopInUFraw
extension. Will have another go tonight. Hopefully have another small
diff by tomorrow.
Are these ok posted to the list, or should I open bug reports for tiny
things like this?
Cheers,
Tim.
On 10/23/07, Stephane Delcroix [EMAIL PROTECTED] wrote:
Nice sugestions. Patches are welcome...
s
On Mon, 2007-10-22 at 22:36 +1000, Tim Thomson wrote:
Hi everyone,
I'm liking the way things are going with RAW processing recently, I
think I might be about to make a full switch back from digikam.
Just a couple of issues I've noticed, Pentax's .pef and .dng
extensions aren't in the IsRaw function so it won't shell out to
ufraw. (src/Imaging/ImageFile.cs line 218). I'm guessing there are
probably a few other ufraw supported RAW filetypes missing?
Also, I think raw.Uri should be escaped when shelling out to ufraw so
that if a picture name has special characters, or someone opts to not
copy files when importing the call to ufraw will still work.
(extensions/DevelopInUFraw/DevelopInUFRaw.cs, line 35 perhaps?)
The PEF RAW thumbnails are not displayed in the main browser, though
the DNG files are. From a quick look at the source it looks like this
is handled by the gnome libs, so I guess once I upgrade gnome it might
start working? It's interesting that they work fine in nautilus
though...
It'd be nice to have f-spot not block when calling ufraw with this
extension, so you could still look at your other photos while
developing to compare, but I guess that would be pretty tricky
currently.
Cheers,
Tim.
___
F-spot-list mailing list
F-spot-list@gnome.org
http://mail.gnome.org/mailman/listinfo/f-spot-list
Index: src/Imaging/ImageFile.cs
===
--- src/Imaging/ImageFile.cs (revision 3434)
+++ src/Imaging/ImageFile.cs (working copy)
@@ -215,7 +215,7 @@
public static bool IsRaw (string name)
{
- string [] raw_extensions = {.nef, .crw, .cr2, .arw, .mrw};
+ string [] raw_extensions = {.nef, .crw, .cr2, .arw, .mrw, .pef, .dng};
foreach (string ext in raw_extensions)
if (ext == System.IO.Path.GetExtension (name).ToLower ())
return true;
___
F-spot-list mailing list
F-spot-list@gnome.org
http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
it's always better to attach patches to bug entries. to the list, if the patch is not applied i nthe next few days, it's lost forever... i'm pushing this one right now... s On Tue, 2007-10-23 at 08:52 +1000, Tim Thomson wrote: I just discovered svn diff, lots easier than diff -u. The attached diff simply adds Pentax RAW file extensions to the list in the IsRaw function. I'm had a slow time compiling and installing the DevelopInUFraw extension. Will have another go tonight. Hopefully have another small diff by tomorrow. Are these ok posted to the list, or should I open bug reports for tiny things like this? Cheers, Tim. On 10/23/07, Stephane Delcroix [EMAIL PROTECTED] wrote: Nice sugestions. Patches are welcome... s On Mon, 2007-10-22 at 22:36 +1000, Tim Thomson wrote: Hi everyone, I'm liking the way things are going with RAW processing recently, I think I might be about to make a full switch back from digikam. Just a couple of issues I've noticed, Pentax's .pef and .dng extensions aren't in the IsRaw function so it won't shell out to ufraw. (src/Imaging/ImageFile.cs line 218). I'm guessing there are probably a few other ufraw supported RAW filetypes missing? Also, I think raw.Uri should be escaped when shelling out to ufraw so that if a picture name has special characters, or someone opts to not copy files when importing the call to ufraw will still work. (extensions/DevelopInUFraw/DevelopInUFRaw.cs, line 35 perhaps?) The PEF RAW thumbnails are not displayed in the main browser, though the DNG files are. From a quick look at the source it looks like this is handled by the gnome libs, so I guess once I upgrade gnome it might start working? It's interesting that they work fine in nautilus though... It'd be nice to have f-spot not block when calling ufraw with this extension, so you could still look at your other photos while developing to compare, but I guess that would be pretty tricky currently. Cheers, Tim. ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
Great !! I think I will re-use f-spot at a more regular basis now. The raw/jpeg merging addins was not working for the same reasons btw. Stephane Delcroix a écrit : enabled in r3419 s ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
enabled in r3419 s On Thu, 2007-10-11 at 20:40 +0200, vescovi christophe wrote: Hi, I do not know if I have to file a bug but it seems that the develop in ufraw extension does not recognise Konica Minolta raw files (.mrw) has valid raw files. I have the following message in the console when trying to use the extention on .mrw files : EXECUTING DEVELOP IN UFRAW EXTENSION The Original version of this image is not a (supported) RAW file regards, Christophe Stephane Delcroix a écrit : An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) - code for keeping Raw+Jpeg together at import time (will make the merge addin obsolete) will come after that hope it clarify the situations a bit... regards s ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
Hi, I do not know if I have to file a bug but it seems that the develop in ufraw extension does not recognise Konica Minolta raw files (.mrw) has valid raw files. I have the following message in the console when trying to use the extention on .mrw files : EXECUTING DEVELOP IN UFRAW EXTENSION The Original version of this image is not a (supported) RAW file regards, Christophe Stephane Delcroix a écrit : An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) - code for keeping Raw+Jpeg together at import time (will make the merge addin obsolete) will come after that hope it clarify the situations a bit... regards s ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
Am Montag, den 24.09.2007, 12:04 + schrieb Olafur Arason: Develop in ufraw appears in everyone's contextual menu. Please use something like Develop the raw image, because some people don't know what ufraw is. And also it should not show up if the user does not have ufraw installed. Then you have to install ufraw to make the menu item visible. That means, you have to know what ufraw is and that you need to install it, but are allowed to forget it thereafter. :-) I would like to vote for the existing title. It allows other (yet to be written) extensions to insert their menu items like Develop in dcraw or Develop in Bibble. Another attempt would be to name it Develop the raw image and add a configuration dialog for the extension wherein the user can select the raw converter of his choice. But that would restrict users from using different converters at the same time. [x] ulf -- Act social. Share your system. http://www.getinternetexplorer.com/ ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
Great work. Just some HIG.. On 9/6/07, Stephane Delcroix [EMAIL PROTECTED] wrote: An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. Please use something like Develop the raw image, because some people don't know what ufraw is. And also it should not show up if the user does not have ufraw installed. - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) - code for keeping Raw+Jpeg together at import time (will make the merge addin obsolete) will come after that hope it clarify the situations a bit... regards s On Tue, 2007-07-17 at 17:57 -0400, Peter Finley wrote: I looked into doing something similar a while ago. I dug around in the code a bit and if I remember right, I found that the biggest issue with this is that the database doesn't support versions of an image with different file type extensions. This means that a JPEG can't be stored as version of a RAW file. I couldn't think of a good solution that didn't involve changing the data model. It may have changed since I looked at it, though (I hope so). It was several months ago. Peter On 7/16/07, David Collett [EMAIL PROTECTED] wrote: Hi all, I've spent a bit of time searching the lists for where RAW support is currently at and where it is headed, but it's still unclear. What follows is a description of a simple workflow which I think would suit many people in the meantime, and should be easy to implement. My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. Ufraw can easily be told via the commandline, how and where to save the output file, suiting f-spot integration. Furthermore, Ufraw can optionally save an ID file which stores the settings used during raw conversion. If desired, this could be saved, so that if the photographer decides they dont quite like their conversion, they only have to right-click and develop again and will start where they left off in ufraw (the resulting jpeg would become yet another version). Batch processing can easily be accommodated too. Suppose you have a set of photos shot in the same conditions and want to batch process them. You can right-click/develop the first one as described above. What this will do is set your current adjustments into your .ufrawrc file (a standard ufraw feature). Now you can select all the remaining photos in the set, right-click and choose develop with UFRAW, when the develop action is invoked with multiple selections, it will launch ufraw-batch instead of ufraw (ufraw-batch comes standard with ufraw). Once the photographer has a good 'developed' jpeg image as a version, they can further edit it with the standard f-spot set of tools (or externally via gimp etc). This may not be the holy-grail of RAW integration in f-spot, but it would be a big step up for those of us currently using f-spot to manage RAW photos. Can other f-spot users let me know what they think of this approach? Can the developers let me know where I might start implementing it? I figure I just need to add a right-click menu item which, when clicked will launch a sub-process (ufraw/ufraw-batch) with the current selection, then wait on the process to complete before re-injecting the resulting jpegs back into f-spot as versions. Sounds easy enough? Thanks, Dave ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
On 9/14/07, Ulf Rompe [EMAIL PROTECTED] wrote: Am Donnerstag, den 06.09.2007, 11:12 +0200 schrieb Stephane Delcroix: An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. Thanks a lot! It may seem pointless to post to a mailing list just to say thank you, but I believe you have just enlarged F-Spot's user base a lot with this single mail. At least you finally got me into the boat. I agree that this is a great feature to have! Thanks a lot for that. I have missed it since I got my DSLR :) Other great features I would like is: * Be able to tag a photo from the command line. Since I have some duplicates of my files placed in folders like print_this, move this to web, etc. I would like to be able to make a short script to make it tags instead. For similar purposes I think it could be usefull to me and others to be able from the command line to: see which tags a photo have too see which photos have a given tag. * Have a mirror of the image repository on my laptop, in a way so I can tag the photos and add new photos on my laptop, without the photos on the laptop is not full size(unless they are added from the laptop). And then when I come back to the desktop be able to import the changes from the laptop. This way I could make tags etc. while being on trains/planes home from something I have fotographed. * I use the Bibble program to do some changes in the images. I would like my workflow to be: 1) import jpeg+raw in f-spot 2) tag the photos I like in f-spot 3) make a new version of one or more photos in Bibble. The output is a .bib in a.jpg where the .bib is Bibbles description of how it transforms the raw file into the jpg 4) If I want Bibble to make new version from an old already bibled version, it should get the raw file and the .bib for that version. I think the last two features requires a lot of work, and the first one should be fairly simple? Regards Anders ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
Am Donnerstag, den 06.09.2007, 11:12 +0200 schrieb Stephane Delcroix: An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. Thanks a lot! It may seem pointless to post to a mailing list just to say thank you, but I believe you have just enlarged F-Spot's user base a lot with this single mail. At least you finally got me into the boat. Right now I'm in the process of importing and sorting my whole image base into F-Spot. It will be a lot of work since, lacking a good photo organizer, my collection has become neglected over the years. But I've been waiting for raw support in F-Spot since it first appeared on the web site as the planned first class raw support. This being a while ago, you can imagine how happy I am now! - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) I will definitely check this out next week since I have lots of derivative files with a revision number as part of the file name (see http://exiflow.sf.net/ for the naming scheme) so your raw+jpeg merger extension can't catch them. But with some manual reparenting (or maybe my first reconnaissance of C# with a slight modification of your extension) I will be able to keep my preprocessing chain as it is with exiflow and then do everything I need with F-Spot. Thank you SO MUCH for that! [x] ulf -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs. ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
On Thu, 2007-09-06 at 11:12 +0200, Stephane Delcroix wrote: An update on the RAW status... - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. You can now install this addin from the UI - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. Add-in for this is available also Both addins require latest f-spot svn s ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
David Collett-3 wrote: WooHoo! You rock! May I play the role of the dumb-one again? I just updated to latest SVN, found the add-ins, installed them. Then tried for a while, but could not locate any new menu options etc. Then I realized that you need to restart f-spot for this to take effect. I suggest that there is a warning sign somewhere in the extensions menu or a button for this. may be there is, but I do not see it! otherwise, stephane, great job! thanks! PS: yep , I will post bug about this if it does not exist. -- View this message in context: http://www.nabble.com/ufraw-%28and-others%29-integration-tf4094160.html#a12573732 Sent from the Gnome - F-Spot mailing list archive at Nabble.com. ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
This is great news! Great work and thanks for the update! Peter On 9/6/07, Stephane Delcroix [EMAIL PROTECTED] wrote: An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) - code for keeping Raw+Jpeg together at import time (will make the merge addin obsolete) will come after that hope it clarify the situations a bit... regards s On Tue, 2007-07-17 at 17:57 -0400, Peter Finley wrote: I looked into doing something similar a while ago. I dug around in the code a bit and if I remember right, I found that the biggest issue with this is that the database doesn't support versions of an image with different file type extensions. This means that a JPEG can't be stored as version of a RAW file. I couldn't think of a good solution that didn't involve changing the data model. It may have changed since I looked at it, though (I hope so). It was several months ago. Peter On 7/16/07, David Collett [EMAIL PROTECTED] wrote: Hi all, I've spent a bit of time searching the lists for where RAW support is currently at and where it is headed, but it's still unclear. What follows is a description of a simple workflow which I think would suit many people in the meantime, and should be easy to implement. My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. Ufraw can easily be told via the commandline, how and where to save the output file, suiting f-spot integration. Furthermore, Ufraw can optionally save an ID file which stores the settings used during raw conversion. If desired, this could be saved, so that if the photographer decides they dont quite like their conversion, they only have to right-click and develop again and will start where they left off in ufraw (the resulting jpeg would become yet another version). Batch processing can easily be accommodated too. Suppose you have a set of photos shot in the same conditions and want to batch process them. You can right-click/develop the first one as described above. What this will do is set your current adjustments into your .ufrawrc file (a standard ufraw feature). Now you can select all the remaining photos in the set, right-click and choose develop with UFRAW, when the develop action is invoked with multiple selections, it will launch ufraw-batch instead of ufraw (ufraw-batch comes standard with ufraw). Once the photographer has a good 'developed' jpeg image as a version, they can further edit it with the standard f-spot set of tools (or externally via gimp etc). This may not be the holy-grail of RAW integration in f-spot, but it would be a big step up for those of us currently using f-spot to manage RAW photos. Can other f-spot users let me know what they think of this approach? Can the developers let me know where I might start implementing it? I figure I just need to add a right-click menu item which, when clicked will launch a sub-process (ufraw/ufraw-batch) with the current selection, then wait on the process to complete before re-injecting the resulting jpegs back into f-spot as versions. Sounds easy enough? Thanks, Dave ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list ___ F-spot-list mailing list F-spot-list@gnome.org
Re: ufraw (and others) integration
I looked into doing something similar a while ago. I dug around in the code a bit and if I remember right, I found that the biggest issue with this is that the database doesn't support versions of an image with different file type extensions. This means that a JPEG can't be stored as version of a RAW file. I couldn't think of a good solution that didn't involve changing the data model. It may have changed since I looked at it, though (I hope so). It was several months ago. Peter On 7/16/07, David Collett [EMAIL PROTECTED] wrote: Hi all, I've spent a bit of time searching the lists for where RAW support is currently at and where it is headed, but it's still unclear. What follows is a description of a simple workflow which I think would suit many people in the meantime, and should be easy to implement. My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. Ufraw can easily be told via the commandline, how and where to save the output file, suiting f-spot integration. Furthermore, Ufraw can optionally save an ID file which stores the settings used during raw conversion. If desired, this could be saved, so that if the photographer decides they dont quite like their conversion, they only have to right-click and develop again and will start where they left off in ufraw (the resulting jpeg would become yet another version). Batch processing can easily be accommodated too. Suppose you have a set of photos shot in the same conditions and want to batch process them. You can right-click/develop the first one as described above. What this will do is set your current adjustments into your .ufrawrc file (a standard ufraw feature). Now you can select all the remaining photos in the set, right-click and choose develop with UFRAW, when the develop action is invoked with multiple selections, it will launch ufraw-batch instead of ufraw (ufraw-batch comes standard with ufraw). Once the photographer has a good 'developed' jpeg image as a version, they can further edit it with the standard f-spot set of tools (or externally via gimp etc). This may not be the holy-grail of RAW integration in f-spot, but it would be a big step up for those of us currently using f-spot to manage RAW photos. Can other f-spot users let me know what they think of this approach? Can the developers let me know where I might start implementing it? I figure I just need to add a right-click menu item which, when clicked will launch a sub-process (ufraw/ufraw-batch) with the current selection, then wait on the process to complete before re-injecting the resulting jpegs back into f-spot as versions. Sounds easy enough? Thanks, Dave ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
An update on the RAW status... - since a few days, db supports versions of images with different extensions - I wrote an addin that'll help you fix your actual db by merging raw +jpeg files of the same image as only one image with versions. This will be available very soon via the 'Manage extensions' menu entry. - I wrote a patch for ufraw and it was accepted so f-spot can force the output file while converting to raw. I still have to write an addin so it Develop in ufraw appears in everyone's contextual menu. - the code for reparenting an image as version of another dy drag'n drop is already in trunk, just not compiled yet (compile with -d:ENABLE_REPARENTING if you want to give it a try) - code for keeping Raw+Jpeg together at import time (will make the merge addin obsolete) will come after that hope it clarify the situations a bit... regards s On Tue, 2007-07-17 at 17:57 -0400, Peter Finley wrote: I looked into doing something similar a while ago. I dug around in the code a bit and if I remember right, I found that the biggest issue with this is that the database doesn't support versions of an image with different file type extensions. This means that a JPEG can't be stored as version of a RAW file. I couldn't think of a good solution that didn't involve changing the data model. It may have changed since I looked at it, though (I hope so). It was several months ago. Peter On 7/16/07, David Collett [EMAIL PROTECTED] wrote: Hi all, I've spent a bit of time searching the lists for where RAW support is currently at and where it is headed, but it's still unclear. What follows is a description of a simple workflow which I think would suit many people in the meantime, and should be easy to implement. My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. Ufraw can easily be told via the commandline, how and where to save the output file, suiting f-spot integration. Furthermore, Ufraw can optionally save an ID file which stores the settings used during raw conversion. If desired, this could be saved, so that if the photographer decides they dont quite like their conversion, they only have to right-click and develop again and will start where they left off in ufraw (the resulting jpeg would become yet another version). Batch processing can easily be accommodated too. Suppose you have a set of photos shot in the same conditions and want to batch process them. You can right-click/develop the first one as described above. What this will do is set your current adjustments into your .ufrawrc file (a standard ufraw feature). Now you can select all the remaining photos in the set, right-click and choose develop with UFRAW, when the develop action is invoked with multiple selections, it will launch ufraw-batch instead of ufraw (ufraw-batch comes standard with ufraw). Once the photographer has a good 'developed' jpeg image as a version, they can further edit it with the standard f-spot set of tools (or externally via gimp etc). This may not be the holy-grail of RAW integration in f-spot, but it would be a big step up for those of us currently using f-spot to manage RAW photos. Can other f-spot users let me know what they think of this approach? Can the developers let me know where I might start implementing it? I figure I just need to add a right-click menu item which, when clicked will launch a sub-process (ufraw/ufraw-batch) with the current selection, then wait on the process to complete before re-injecting the resulting jpegs back into f-spot as versions. Sounds easy enough? Thanks, Dave ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list ___ F-spot-list mailing list F-spot-list@gnome.org
Re: ufraw (and others) integration
Stephane Delcroix wrote: My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. You still have some time to take a flight to GUADEC and attend jimmac's talk on Friday... Stephane, sorry, I do not get what you mean by this comment. Is this some sort of good news that we will have open in ufraw implemented in the way the poster mentioned or not? thanks, turgut -- View this message in context: http://www.nabble.com/ufraw-%28and-others%29-integration-tf4094160.html#a11692092 Sent from the Gnome - F-Spot mailing list archive at Nabble.com. ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: ufraw (and others) integration
My ideal workflow would be something like this: 1. import RAW files directly from camera/memcard 2. right-click desired photo and select develop in UFRAW 3. UFRAW would be launched where I can perform RAW developing. 4. When UFRAW is closed, the resulting jpeg would be automatically added as a version of the original raw image. You still have some time to take a flight to GUADEC and attend jimmac's talk on Friday... -- Stephane Delcroix [EMAIL PROTECTED] ___ F-spot-list mailing list F-spot-list@gnome.org http://mail.gnome.org/mailman/listinfo/f-spot-list
