Workflow with raw+jpeg
Locked
 
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Hi, the new svn version is *really* good! Now that I've mastered compilation hurdles I can concentrate again on taking pictures. Using a Minolta 7D, I have most of my pictures in raw AND jpg, which allows fast review of the images and having the digital negative for shots that are worth fiddling. What I now start missing in digikam is something like a file format filter which would allow me to view *only* my jpegs when stepping through my shots in the Image Editor. It is nice to be able to view the raw files, too, but the Image Editor takes its time to render them and they are not rotated, so I would prefer to be able to hide them as a whole. This complex leads to another issue: Having raw files and derived work, it would be nice to have the possibility to cluster those. Are there already any thoughts on this issue? Cheers Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEDbcjxxUzQSse11ARAkw5AJ9OYIb6d1hBlorRcl7jQ1LwR3KAdQCeOxM4 XULhdM9EWkKXLQksNT6r9z8= =Xqbq -----END PGP SIGNATURE----- _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Am Dienstag, 7. März 2006 17:38 schrieb Markus Spring:
> What I now start missing in digikam is something like a file format filter > which would allow me to view *only* my jpegs when stepping through my shots > in the Image Editor. It is nice to be able to view the raw files, too, but > the Image Editor takes its time to render them and they are not rotated, so > I would prefer to be able to hide them as a whole. > > This complex leads to another issue: Having raw files and derived work, it > would be nice to have the possibility to cluster those. Are there already > any thoughts on this issue? > > Cheers > > Markus I use different folders (albums) for different file-types and also for untouched pictures and such that I already have worked over. Another idea is, if you temporarily move all jpg's to one folder in the digikam-tree, all raw files to another (with Konqueror or so). Then open digiKam, select all files in the jpg-folder and mark them with a tag like "jpg", select all files in the raw-folder and add tag "raw", finally move all contents of one folder back to the other again. Now you can use digiKam's tags to select the group you want to see, but still have all your photos in the same album... regards Daniel -- Daniel Bauer photographer Basel Switzerland professional photography: http://www.daniel-bauer.com special interest site: http://www.bauer-nudes.com _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Markus Spring
Le Mardi 7 Mars 2006 17:38, Markus Spring a écrit :
> Hi, > > the new svn version is *really* good! Now that I've mastered compilation > hurdles I can concentrate again on taking pictures. > > Using a Minolta 7D, I have most of my pictures in raw AND jpg, which allows > fast review of the images and having the digital negative for shots that > are worth fiddling. > > What I now start missing in digikam is something like a file format filter > which would allow me to view *only* my jpegs when stepping through my shots > in the Image Editor. It is nice to be able to view the raw files, too, but > the Image Editor takes its time to render them and they are not rotated, so > I would prefer to be able to hide them as a whole. I use too Minolta camera Dynax 5D. I recommend you to recompile dcraw (the last version) himself using the max optimization. There are any web site about this subject. Take a look in google. In my host computer (PIV 3.6Ghz), decoding 1 MRW file take 10s only after to have recompiled dcraw (18s before). > > This complex leads to another issue: Having raw files and derived work, it > would be nice to have the possibility to cluster those. Are there already > any thoughts on this issue? Sorry for my poor English. I don't understand what you mean exactly by "cluster" ? Gilles _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Tuesday 07 March 2006 20:18, Gilles Caulier typed:
> Le Mardi 7 Mars 2006 17:38, Markus Spring a écrit : > > This complex leads to another issue: Having raw files and derived work, > > it would be nice to have the possibility to cluster those. Are there > > already any thoughts on this issue? > > Sorry for my poor English. I don't understand what you mean exactly by > "cluster" ? Not to speak for Markus, but it's possibly what I'm thinking of. Every file has a unique fingerprint, and this can be represented by a SHA1 or MD5 digest of the file data. If digiKam were to store the digest in the database of each file name, and showFoto played nicely, it would be possible to say 'file with sha 123 is a child of file with sha 999. file with sha 432 is also a child of 999'. With that kind of linking present, the interface is now one step closer to 'right-click this file, show me all children' - grouping or clustering all of the child photos that are linked by modifications around the master file. Taking the linking in reverse, you can also say 'show me all related photos' - this would find the parent link, and from the parent find all other children. The tree of links can get fairly deep, but the algorithms for dealing with trees in SQL are well published and from what I remember, fairly fast, especially since (I'm guessing) most people will have a root node, and maybe 5 child nodes (master image, child images). This extends into something I've been pondering - the ability for digiKam and showFoto to collaborate and somehow store the actions and values used to generate a photograph. Given a series of actions and values, I can re-create any edited image in my collection - once I have the master file. To extend it further, provide a way to export the actions and values as a script file. I can now edit the script file, and re-run it against the same master file to get a different child - and running it would be from within showFoto or digiKam so the database gets updated. Oh, and finally, for existing collections, merely (hah!) provide a way to select 2 photos, and set one as parent. The other is immediately a child. There is the limited case where a child might have multiple parents - a collage image. I haven't considered how to deal with that. And really finally, the benefit of using the fingerprints in the database means that digiKam becomes resistant to external tampering by file managers and fingers. When a file goes missing, but the same checksum appears in another album, merely update the database to point to the new album. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 > On Tuesday 07 March 2006 20:18, Gilles Caulier typed: >> Sorry for my poor English. I don't understand what you mean exactly by >> "cluster" ? Grouping together of similar images Duncan explained quite well what belongs to this thematic complex, and as he extended the original extent of my mail pretty much I will just take the opportunity to emphasize what I see as the baseline of a "clustering" feature. * Signalising that some image files belong to a group - besides doing this through tagging - can clarify relations between files. Especially when you use raw files you will probably end up with more than one version derived from this digital negative, but even when you just create a downscaled version for web purposes from a jpeg you already have a group of files with a close relationship. Parent-Children is a good naming scheme for this * At least for my working style it makes sense to keep the files of maybe a short trip in one folder. Having additional visible information that certain files belong together (maybe a dotted line around the group) helps when scanning an album. * The possibility to hide the children and unfold the group additionally would increase the oversight. Now for Duncans idea of using hashes to identify the images: Digikam is already quite robust when it comes to moving files around albums as long as the file names are not changed. Hashes would increase this robustness even to the case when somebody renames a file. However calculating checksums takes some time (and I *am* already impatient when waiting for the thumbnails to get generated) so this might best be deferred to a background thread. The idea of saving and re-applying actions to images would mean a complete scriptable interface for the image editor - this sounds alluring but will be a major challenge in itself. Again it is a matter of preferences and personal workflow, but I myself do all major editing in gimp and do not use the digikam image editor so often. Ufraw does a fantastic job for converting the raw files, and the possibility to save the conversion profile really lays the foundation for iterative refinement of images. My personal focus when using digikam is organising and reviewing my images. Therefore I welcome all improvements in this field very much. The new layout, the introduction of the timeline are all steps I do appreciate very much. Having the possibility to tag groups of files and to do this with lesser mouse movements would make it even better for me. The usability of digikam is already really high. I have introduced my 72 years old father, who was computer-illiterate before, into linux and digikam and he does get along very good! Therefore I send a big thank you to you, Gilles! regards Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEDyc1xxUzQSse11ARAvkpAJ4uGZ+j8dFWtODr9fx818dcYMdXewCfSbeG Vzo6oAlx278OVi7YfvB89yw= =RhWA -----END PGP SIGNATURE----- _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Wednesday 08 March 2006 07:49 pm, Markus Spring wrote:
> > On Tuesday 07 March 2006 20:18, Gilles Caulier typed: > >> Sorry for my poor English. I don't understand what you mean exactly by > >> "cluster" ? > Ducan, Markus, Your wishes are impressive but out of digikam 0.9.0 issue. I recommend you to make a new files in B.K.O and let's digiKam users commented yours files. Gilles > Grouping together of similar images > > Duncan explained quite well what belongs to this thematic complex, and as > he extended the original extent of my mail pretty much I will just take the > opportunity to emphasize what I see as the baseline of a "clustering" > feature. > > * Signalising that some image files belong to a group - besides doing this > through tagging - can clarify relations between files. Especially when you > use raw files you will probably end up with more than one version derived > from this digital negative, but even when you just create a downscaled > version for web purposes from a jpeg you already have a group of files with > a close relationship. Parent-Children is a good naming scheme for this > > * At least for my working style it makes sense to keep the files of maybe a > short trip in one folder. Having additional visible information that > certain files belong together (maybe a dotted line around the group) helps > when scanning an album. > > * The possibility to hide the children and unfold the group additionally > would increase the oversight. > > Now for Duncans idea of using hashes to identify the images: Digikam is > already quite robust when it comes to moving files around albums as long as > the file names are not changed. Hashes would increase this robustness even > to the case when somebody renames a file. However calculating checksums > takes some time (and I *am* already impatient when waiting for the > thumbnails to get generated) so this might best be deferred to a background > thread. > > The idea of saving and re-applying actions to images would mean a complete > scriptable interface for the image editor - this sounds alluring but will > be a major challenge in itself. Again it is a matter of preferences and > personal workflow, but I myself do all major editing in gimp and do not use > the digikam image editor so often. Ufraw does a fantastic job for > converting the raw files, and the possibility to save the conversion > profile really lays the foundation for iterative refinement of images. > > My personal focus when using digikam is organising and reviewing my images. > Therefore I welcome all improvements in this field very much. The new > layout, the introduction of the timeline are all steps I do appreciate very > much. Having the possibility to tag groups of files and to do this with > lesser mouse movements would make it even better for me. > > The usability of digikam is already really high. I have introduced my 72 > years old father, who was computer-illiterate before, into linux and > digikam and he does get along very good! Therefore I send a big thank you > to you, Gilles! > > regards > > Markus > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Thursday 09 March 2006 06:51, Gilles Caulier wrote:
> On Wednesday 08 March 2006 07:49 pm, Markus Spring wrote: > > > On Tuesday 07 March 2006 20:18, Gilles Caulier typed: > > >> Sorry for my poor English. I don't understand what you mean exactly by > > >> "cluster" ? > > Ducan, Markus, > > Your wishes are impressive but out of digikam 0.9.0 issue. I recommend you > to make a new files in B.K.O and let's digiKam users commented yours files. *nod* I fully intend to, but I think I want to flesh the idea out first to give people more food for thought :) Thank you Gilles, and all other digiKam contributors :) _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |