Re: f-spot in a photo workflow

[Jenner Fusari <jenner neurotix com>]

Hi all,
I really liked to read your workflow Aigars. I decided to fall in my 
(long) paper of dream-features.

> It would be very nice if we could make a discussion about that
> and build a roadmap of new features for F-Spot based on that
> workflow.

My workflow is quite similar (or I expect to reach - a day - such a 
workflow) to yours until point 8.
The main differencies in the first 8 points, in my workflow, are the use 
of self-made scripts that copies the photos from the camera to a 
"pre-import"/"staging" directory. After sticking in that directory I do 
the import in F-Spot.

After running those scripts (and we go beyond the point 8), I come to a 
situation where I would really like to be helped from F-Spot.
I often have many shots that will go to image post-processing: shots for 
panoramic compositions, shots for HDR compositions (like making an 
OpenEXR image with PFSTools or, in GIMP, using blending techniques), 
shots for macro compositions (like blending some macro shots with narrow 
depth of field in order to get a wider one). In my workflow this group 
of photos for post-processing are equal to a single images. So I will 
really need to create projects.
It is absolutely not easy for me to group this images for 
post-processing with tags: can't create a tag to say that they are part 
of that other image... I'll get an explosive proliferation of tags!... 
What I expect to do is selecting the photos, grouping them with a 
particular "project tag", naming it (a title) and adding some notes to 
the group... when I finished the post-processing a new image comes out 
and I expect to create a relation from this image to its project (its 
group of images).
I talk about "project tag" as a tag that groups selected shots by the 
process that they will follow. That's the way I imagine this tags should 
work: I create a "project tag" for panoramas, I bound to this tag it's 
default open application (such as Hugin or a bash-script), I bound to 
this tag some other customized functions (like "rebuild panorama" that 
will - for example - run a PTStitcher script). As a default behaviour of 
"project tags" I will expect a function like "add file to project", that 
will help me improving the integrity of the project by bounding to the 
group of photo their own scripts (and maybe leaving a note about the 
added file).
In the same way I can create a "project tag" for HDR images (I use 
PFSTools for assembling different exposures together coming to an 
OpenEXR image): I would set the default application to Cinepaint, I 
would bound a customized function like "build OpenEXR image" that calls 
my script and I would "add to the project" the .hdrgen and the 
camera.response files.
As you can see a "project tag" can't mix together the photos (like 
"standard tags") of that type of project... "OpenEXR HDR image" "project 
tag" can't mix together all the photos involved in a process of 
composing an HDR Image... maybe filtering on this tag will show you all 
the projects (for every project I can see its title and the thumbnails 
of the resulting final images - if there's no final images bounded to 
the project I think it's better to see a gray "no final image yet" 
text... so I can always know which work is finished and which not).
Continuing about "project tags" it's really important that the final 
image, when bounded to the project, should get the same date/time of one 
of its source shots... maybe copying EXIF data from the source shot to 
the final image using exiftool?
The real mess - for me - comes out when I build an HDR panorama. 
"Project tag" can help me to simplify the work: I would create many 
different panorama projects from source images using the "Panorama" 
"project tag"; I will come to many panoramic final images so I will 
group those final images in a "OpenEXR HDR image" "project tag" that 
will come to the real final image (F-Spot never need to say that this 
last is the real final image).

In my workflow I don't need F-Spot image editing capabilities... got too 
much customized stuff around to ask F-Spot implementing it: UFRAW is my 
RAW conversion toy, I expect only that F-Spot is able to call it; Hugin 
is my tool for panoramas, if would have "project tags" I only expect 
that F-Spot is able to call Hugin... and so on.
Maybe I would really like to manage in F-Spot other image kinds like 
OpenEXR or XCF (and just saying which application has to be used to open 
it)... thumbnailing isn't a must-have feature for this formats, for me 
it's good even if F-Spot just requiring me to provide a separated JPEG 
thumbnail image.

Performance are a sensible point in my day experience... expecially 
because I run a PentiumIII 800MHz machine with 384MB RAM! ;) ...so I 
can't ask for "Speeds in the order of 2 photos per second" on loading 
RAW images: loading a RAW in UFRAW takes about 3 seconds on my machine! :D
Any performance speed-up is welcome... even loading 2 RAWs per second on 
my machine! ;)
BTW I can't figure how F-Spot can comes to use even 550MB of swap while 
using it intensively (my luck is that I got a 1GB swap partition)... 
when F-Spot comes to such swap level I need to stop sticking with it for 
at least 6/7 minutes.

Finally I would be happy if the interface can be improved even for a 
resolution of 1024x768: F-Spot is just ahead compared to similar 
projects and I think it can be even better... please don't forget those 
who use 1024x768! :)

Bye
   Jenner