Re: RAW/Versioning improvement ideas

["Peter Finley" <pezskwerl gmail com>]

I don't think that this would be a problem since as you said the JPEG when shooting RAW+JPEG is a version of the RAW (created by the camera).  So, as long as the JPEG had the same base filename and is in the same directory as the RAW it would work.

On 11/1/06, Antti Ahonen <aahonen gmail com> wrote:

I have been wondering about the same thing myself.

The problem with automatically detecting the files (thing #3) might be
proglematic, because if you are shooting both raw and jpg, you will
already have a JPG file with the same name.

Then again it is a version of the same picture as well, so maybe it
would be the right way after all.

The converted Raws would be img_0001-2.jpg and so on.

On 11/1/06, Peter Finley < pezskwerl gmail com> wrote:
>
>
> Hello,
>
> I am new to the list and am looking to get involved in developing this
> application.
>
> To start, I would love to help improve the RAW support. I don't know what
> the current plan is for this functionality, but currently, F-Spot does not
> support versioning with RAW photographs. I know that many photographers
> (including myself) shoot only in RAW and it is a major drawback to not be
> able to manage versions of RAW images as with other image types (like JPEG).
>
> I see a few options to here remedy this dilemma (I'm sure some of them have
> already been suggested):
>
>
> Implement a RAW converter (dcraw) into the F-Spot code. However, I think
> most people currently use the excellent UFRaw application, which might be
> hard to compete with. This would be the nicest, most clean solution, but
> also the most intensive if it is to compete with UFRaw.
>
>
> Implement the ability to manage versions. This would include the ability to
> take an image and add it as a version of a different image. Originally, I
> was thinking this could be done by selecting and dragging one or more images
> onto an other in the query view. I looked into actually implementing
> something like this only to find that versions must have the same file
> extension. Obviously, for this functionality to be possible this limitation
> would need to be fixed in the database (add a 'path' field to the
> 'photo_versions' table or change the 'version_id' to be a FK to
> 'photos'.'id' instead).
>
>
> Add some code to automatically detect converted RAW files during the import
> process. For instance, say there is a RAW file called 'img_0001.cr2'. Most
> often a file converted from this will retain the same base filename, such as
> 'img_0001.jpeg'. During the import process, this could be detected and the
> JPEG file could be automatically added as a version of the RAW file. Again,
> this suffers from the same limitation of #2.
>
>
> Somehow intelligently support UFRaw so that F-Spot has some control over the
> conversion process. For instance, I noticed that ufraw-batch can output to
> standard out or to a designated file. This could allow for F-Spot to spawn
> the ufraw-batch process on some selected RAW files and specify the output
> file (or read from standard out). The ufraw-batch process will use the
> configuration file stored in the user's home directory (~/.ufrawrc) to
> perform the conversion.
>
> Personally, I would be content with only having option #3. This would allow
> for RAW files to be converted outside of F-Spot and automatically imported
> as a version of the original RAW file, so long as the converted versions are
> in the same directory as the RAW and have the same base filename. In fact,
> this same logic could be applied to other situations, such as if there is a
> file 'img_0001.tiff' and a 'img_0001.jpg' in the same directory, the JPEG
> could be add detected and added as a version of the TIFF upon being
> imported. Going a step further (and dreaming a little bit), it would be even
> nicer to have a version tree instead of a flat list. That way you could have
> a base RAW file, several different TIFF versions at the next level and JPEG
> versions of those, or something to that effect. Maybe overkill, but an idea
> anyway.
>
> Anyway, I am interested in hearing all of your thoughts and I look forward
> to hopefully contributing this excellent application.
>
> Thanks,
>
> Peter
>
> BTW, I am willing to implement any of the above solutions (or others).
> _______________________________________________
> 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