As mapivi needs to have a jpg one might consider using dcraw to get such a jpg from the raw for preview (a comment in mapivi code refers to nefextract but that would only work for Nikon; dcraw handles a lot more formats). According to the man-page of dcraw:
[...]
-e Extract the camera-generated thumbnail, not the raw image. You'll get either a JPEG or a PPM file, depending on the camera.
[...]
Thus, using
dcraw -e myfile.nef
produces a neat lower quality myfile.thumb.jpg out of the raw. The nice thing is it does so in almost no time! Its dimensions are even almost the same as the real jpg (4288x2848 vs. 4352x2868 on my D90) so it can be considered usable at least for thumbnail generation, indeed. Calling dcraw against the plain raw to create a ppm out of it seems not advisable as the result is actually pretty bad compared to the thumbnail if dcraw does not get suitable parameters. Besides, developing the raw to ppm that way also takes quite some time while extracting the thumbnail is really fast.
A workflow for mapivis importer with raw support might now use dcraw to fetch those thumbnails (imagemagick could be used to convert ppm to jpg in case necessary) and use them to make the raws accessible within mapivi. If the current state should be preserved, it would be enough to rename myfile.thumb.jpg to myfile.jpg and one is done. This has the drawback that the user does not get any feedback from the thumbnail that it is in low quality and that actually the raw should get processed beforehand as mapivi can not disinguished the finalized jpg from the intermediate thumbnail.
Therefore it seems advisable for mapivi to learn to deal with .thumb.jpg and signify the user by some means that work has to be done here. The existence of .thumb.jpg could be used as a marker. Once the raw is processed to jpg mapivi could detect the existence of .jpg, regenerate its internal thumbnail based on the .jpg and remove the .thumb.jpg. IMHO this would give a pretty nice raw workflow support already.
Still, for a work around that would do it _today_ one could e.g. mount the camera via gphotofs or use the card in some card reader, fire up a small script that:
- transfers the raws to some tempdir
- calls dcraw -e against them
- renames the .thumb.jpg to .jpg.
Then one could easily run mapivi's importer against the temp dir fetch the photos from there and proceed. Setting mapivi to delete the source files would even do automatic cleanup of the tempdir.
To integrate raw conversion I played around with invoking a raw converter from within mapivi by means of a plugin. This is actually pretty easy as one could just start out from the test-plugin and add a simple system() call to the raw converter instead of just printing out the file name given to the plugin. This worked pretty well with either ufraw and Rawtherapee as converters. The main drawback here is that mapivi seems to wait for the plugin to return which can take a while if I put up a number of raws in Rawtherapees batch queue or whatever. It would be nice (not only for this case) if one could shell out within a plugin such that mapivi does not wait for the external to return. Either this is not possible or I did not find a hint in the docs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As mapivi needs to have a jpg one might consider using dcraw to get such a jpg from the raw for preview (a comment in mapivi code refers to nefextract but that would only work for Nikon; dcraw handles a lot more formats). According to the man-page of dcraw:
[...]
-e Extract the camera-generated thumbnail, not the raw image. You'll get either a JPEG or a PPM file, depending on the camera.
[...]
Thus, using
dcraw -e myfile.nef
produces a neat lower quality myfile.thumb.jpg out of the raw. The nice thing is it does so in almost no time! Its dimensions are even almost the same as the real jpg (4288x2848 vs. 4352x2868 on my D90) so it can be considered usable at least for thumbnail generation, indeed. Calling dcraw against the plain raw to create a ppm out of it seems not advisable as the result is actually pretty bad compared to the thumbnail if dcraw does not get suitable parameters. Besides, developing the raw to ppm that way also takes quite some time while extracting the thumbnail is really fast.
A workflow for mapivis importer with raw support might now use dcraw to fetch those thumbnails (imagemagick could be used to convert ppm to jpg in case necessary) and use them to make the raws accessible within mapivi. If the current state should be preserved, it would be enough to rename myfile.thumb.jpg to myfile.jpg and one is done. This has the drawback that the user does not get any feedback from the thumbnail that it is in low quality and that actually the raw should get processed beforehand as mapivi can not disinguished the finalized jpg from the intermediate thumbnail.
Therefore it seems advisable for mapivi to learn to deal with .thumb.jpg and signify the user by some means that work has to be done here. The existence of .thumb.jpg could be used as a marker. Once the raw is processed to jpg mapivi could detect the existence of .jpg, regenerate its internal thumbnail based on the .jpg and remove the .thumb.jpg. IMHO this would give a pretty nice raw workflow support already.
Still, for a work around that would do it _today_ one could e.g. mount the camera via gphotofs or use the card in some card reader, fire up a small script that:
- transfers the raws to some tempdir
- calls dcraw -e against them
- renames the .thumb.jpg to .jpg.
Then one could easily run mapivi's importer against the temp dir fetch the photos from there and proceed. Setting mapivi to delete the source files would even do automatic cleanup of the tempdir.
To integrate raw conversion I played around with invoking a raw converter from within mapivi by means of a plugin. This is actually pretty easy as one could just start out from the test-plugin and add a simple system() call to the raw converter instead of just printing out the file name given to the plugin. This worked pretty well with either ufraw and Rawtherapee as converters. The main drawback here is that mapivi seems to wait for the plugin to return which can take a while if I put up a number of raws in Rawtherapees batch queue or whatever. It would be nice (not only for this case) if one could shell out within a plugin such that mapivi does not wait for the external to return. Either this is not possible or I did not find a hint in the docs.