“Sorting the photos: Using darktable, what I really miss is doing sorted collection as preparations for photo books. Of course I can add all images that may be used in the project into one collection by adding a tag, but there is no possibility to bring them into an arrangement that reflects their order in the book.”
+1 for this feature. I also would like to sort images within a Filmroll/Folder in a custom way. I remember Adobe Bridge could do this. Afaik there are nearly no apps (for Mac) around that let you sort your images your way. It would be a great feature in Darktable.
I already thought a bit about an implementation. The problem is that, IIRC, in darktable every (xmp+raw) file double has to be self-consistent. I would therefore and for other reasons prefer to have a solution that is reflected in the xmp files and does not only rely on the data base. A possible implementation could be to give every raw file a UID (e.g. by checksumming the raw file) and refer to the next and previous ordered list entries (or only one of these) within every xmp. Unfortunately this would break if one element is removed from outside darktable. One could add some redundancy by tracking a number of subsequent UIDs within each xmp and/or rely on the database to recover from removal outside darktable whenever an image that has references is loaded by checking all corresponding xmps and rewriting them if necessary.
Unfortunately I lack the necessary programming skills to start such an implementation.
I believe darktable writes it most of its database content to the xmp file regularly, unless you’ve turned that preference off.
You could come up with your own XML schema for xmp to order things, but that’d get messy fast. You could use tags in darktable to order, as in order|001, order|002 etc.
That would not allow to move images around very easy, because for the worst case, every xmp would have to be rewritten. Therefore my idea with the linked list which would require only three files (for the minimal list case without redundancy) to be changed if one file is moved: The moved file, the old predecessor and the new predecessor.
To make it more clear:
But to be efficient in finding the starting point of the list, one would probably have to implement a scheme that links next and previous list item.
Of course this could be implemented solely by using tags as storage. Probably a lua solution is possible. Only the sorted display of the images would be difficult to implement that way.
I haven’t been following this thread but in the past I made a small newsletter using Inkscape. It was a single edition and by my own volition when I was volunteering with a non-profit. It probably wouldn’t be a good idea to use Inkscape for designing a photo book because it can be buggy and, as far as I know, it doesn’t have proper color management.
What I found useful at the time was creating templates with placeholders for text and images. Each placeholder would have a variable to which I would link an object. Each page would be a new layer. Then I would export every layer and combine them into a publication using a PDF editor. It was so long ago, so I forgot exactly how I did it.
I do calendars for the family in inkscape every year, about 8 individual ones, and the biggest issue is the missing multipage support. I see this feature on the horizon (or on inkscape roadmap) for >> 10 years, and am still waiting. Dealing with 8 X 13 svg files every year.
Yes, the pace of their development is pretty slow . (I wonder if it is worth it to add the Inkscape community to this forum even though it isn’t exactly for photography to grant them more visibility.)
I would not say that in general, for some features the development is pretty fast, I would say the feature development is rather web-centric and the web does not care about multipage documents.
From my side +1 for adding the inkscape community since for me adding a photo to an end product such as a calendar or a book cover or … is part of the photographic process. But most people today think only about Facebook or their blog as destination for their photos.
I don’t think inkacape is the best tool for the job here, but it is certainly a program that is straight forward and will make a PDF.
Digging into Scribus more, my main question is how to present the information without it being a desktop publishing primer. Even as I see it now, this will be a fairly lengthy article and there are so many places where if you don’t get it just right (color management, bleed, trim), it just won’t look right.
I would say, that the todo list should look like this:
Create a (small) photo book in Scribus manually, to check if it is the right tool.
I can write a Lua script, that exports the selected images in darktable and starts scribus with parameters. (It is possible to start Scribus with parameter, that runs a script in Scribus.)
We need a Python script in Scribus that does the work there. There are already the scripts @paperdigits found. Someone needs to modify this scripts to run with parameters from the command line and without GUI.If that is done we can call this script from the Lua script in dt.
The ordering in darktable is a minor point and could be earliest fixed in a release next year, because dt is in feature freeze for 2.4. Perhaps you can write a bug report with a detailed description, how this should look like. It is possible to tag photos in dt. And it is possible to write a simple Lua script to export the selected photos and name the files like the tags. But that is of cause not very user friendly.
To scribus darktable interaction: I don’t think a scribus export is necessary as long as there is no two-way communication. From my experience I know that after exporting the photos there is a lot of work on the layout and moving the images around and changing the images etc. and this would require to be able to go back to the raw developer at every state of the layout. If this is not possible, the initial layout could be generated without darktable interaction, because it would be only the initial design.
The ordered collections point would be the more important one since it would help in the preselection of the photos. While I could write a feature request, I have done too many of them and feel a guilty conscience already (is this correct English?).
Which one do you mean? The sorting thing? This was described in this thread before (see the big blue sketch).
And the scribus darktable interaction? What I mean is that an image could be linked between scribus and darktable, such that a change in darktable will update the image in scribus and that you have the possibility in scribus to e.g. right click and select a context menu entry to get back into darkroom of darktable with the image opened. An explicit export would not be required in that case, but an UI for linking the image in dt and scribus would be necessary.
One important aspect (this feature idea I already described somewhere else here on pixls.us) would be that the crop in darktable is only used for an initial crop in scribus and that the image parts cropped away are available if necessary, e.g. to fill page bleed etc. A change of crop in scribus should not be reflected back to darktable, since in darktable it is an artist’s decision which crop is selected and in scribus it is the designer’s need to deviate from the artist’s decision .
For this purpose, the export location would probably be a hidden cache folder, e.g. the darktable config folder. Some little problems would have to be solved anyway, e.g. the cache would have to be rebuilt if it is deleted (automatically triggered by scribus or manually from darktable), scribus would have to trigger the export from darktable if something is missing, scribus would have to watch the cache for changes etc.
Therefore I said above
(… while I still think the raster image bounding box crop thing would be extremely useful and the sortable collections feature would be useful anyway).
.
.