Absolutely, thanks for the clarification! I’ll make sure to mention it. 
1 Like
Regarding the goal of the OP I suggest a flowchart showing possible steps and software / techniques used. Maybe it could also be an image map with links pointing to posts or articles?
1 Like
I’ve started a gist on github for a flowchart, as suggested by @parallax. It is using the graphviz format.
If you have the graphviz package installed, you can use the following command to see the image
curl https://gist.githubusercontent.com/paperdigits/21ad48ec7cb689436d06cf9ff5c88a38/raw/7236c655c96e48afdac7e95fc1ebda7fabde1342/beginner_photo_workflow.dot | dot -Tpng -o test.png
I don’t know why the subgraph commands are not working; I’d like to get them working to label some steps.
1 Like
Filmulator could feed into krita, gmic, or gimp. It’d make the chart messy, though…
Lots of tools could feed into lots of tools. Choice is one of the best and worst things about free software. Considering this is geared at beginners or people not familiar with a free software workflow, I think we should try and keep it simple. In fact, I think my flowchart is already too complicated. Getting lost in the weeds would be extremely unhelpful in this case.
The broad strokes that need to be addressed, I think, are:
- I have files on my camera and want to get them on my computer.
- I want to view and/or manage my photographs.
- I want to use a program that can make changes to raw files.
- I want to edit pixels.
I would not show what can be done, but what is recommended, personal preference aside. The former would make the chart convoluted and not really help anyone. For example, just because you can pass an image from digiKam into UFRaw doesn’t mean that is a recommended workflow; digiKam handles basic raw processing just as well as UFRaw, passing an image from digiKam into UFRaw doesn’t really get you anything, and dt and RT are far more capable than UFRaw, so if you are going to go through the hurdle of moving your images from one program into another, make it a combination which complements each other.
Secondly, if the programs are grouped by stages, some should be listed more than once, for example digiKam belongs in the image transfer from source group (it has a dedicated image import module), the DAM group (its main task is managing photos), the raw development group (it has basic raw development capabilities) as well as the final group (it can add watermarks and frames, it can export, upload, etc). It would be beneficial for someone to see that one program can do all that.
2 Likes
I think @Morgan_Hardwood is right. The route is more “how to write a beginners tutorial” than “how to write a scientific paper”. There is no need to be comprehensive. I really love the new tools that are discussed here such as photo flow and filmulator, but for a beginners tutorial I would recommend to start with the “old” and mature solutions, which have the benefit that there is a lot material to learn from available (even if we consider a lot of what’s e.g. on youtube not good enough, it has some critical mass).
That does not mean that the new tools should entirely be left aside. If it is a written tutorial, I would spend a whole chapter or two for these, just to emphasize the possibilities that are available. But this chapter is at the end of the book.
For the typical workflow graphs, I would do a much simpler representation. Even this
is a bit too complicated (graphviz code below, and it is just a rough sketch, there may be many errors in this graph). For a beginners tutorial, it is enough to give a reasonable starting point. In the left graph, one could add tooltips that show when the different routes make sense (e.g. the “tiff” route for heavy retouching, etc.). Maybe it makes sense to skip the “raw on hdd → output” route, since tagged/cataloged raws is something we should not de-recommend. Does rawtherapee this dam stuff as well?
Just some thoughts …
The code:
digraph {
subgraph clustera {
label = "typical raw workflows"
"raw on camera" -> "raw on harddisk" [label="rapid photo downloader\ndarktable\nfile manager"]
"raw on harddisk" -> "catalogued raw" [label="darktable\ndigikam"]
"catalogued raw" -> "intermediate file (e.g. tiff)" [label="darktable\nrawtherapee"]
"intermediate file (e.g. tiff)" -> "output file (e.g. jpeg)" [label="gimp\nkrita"]
"catalogued raw" -> "output file (e.g. jpeg)" [label="darktable"]
"raw on harddisk" -> "output file (e.g. jpeg)" [label="rawtherapee"]
}
subgraph clusterb {
label = "typical panorama workflow"
"raw on harddisk " -> "intermediate files (e.g. tiff) " [label="rawtherapee"]
"catalogued raw " -> "intermediate files (e.g. tiff) " [label="darktable"]
"intermediate files (e.g. tiff) " -> "panorama file (e.g. tiff)" [label="hugin"]
"panorama file (e.g. tiff)" -> "output file (e.g. jpeg) " [label="darktable\nrawtherapee\ngimp"]
}
subgraph clusterc {
label = "typical hdr workflow"
"..."
}
}
2 Likes
Yes, you can assign ratings and other metadata in the RT File Browser as well.
I like your idea of specific workflows for panorama and single shot, you could easily add HDR to this as well.
I think part of what I was thinking initially was to step into the shoes of a first-time user of either Free Software, or digital photography + Free Software.
For instance, I’d be surprised if a first workflow for most folks wouldn’t be simply shooting jpeg and then wanting to touch up those images in some way a little. What would that workflow look like typically? (This is the simplest case, of course).
Maybe this should be multiple articles, with each focusing on a particular workflow from a recommended workflow (as @Morgan_Hardwood suggested), and filling out some extra information for further study if they desired. Hell, at this point most folks probably don’t even know then name of what options might be available (as evidenced from the number of Lr users that actually pay to use Enfuse for the love of pete! http://www.photographers-toolbox.com/products/lrenfuse.php).
I like that we’re revisiting this topic, and I apologize for letting it languish for so long! I will be pushing the main website source code up to Github soon, so we’ll at least have some stuff to work against and be ready to accept contributions properly.
In the meantime, what does everyone think about breaking this up into separate articles where we address common/recommended workflows + software for some scenarios:
- Shoot/Process JPG (first-timers!)
- Shoot/Process raw
- Panorama
- HDRi
- Night/Astro (stacking, etc?)
- Macro (calling @andabata here)
Sounds reasonable, especially since these workflows really differ in the used software “route”. Some topics that are IMO missing but may due to their general nature deserve their own article:
- Printing photos (which may be of special interest concerning the FLOSS options solely)
- Scanning photos (also special from the FLOSS point of view)
- Colour management (an advanced topic, but a good overview article on FLOSS colour management would be extremely helpful to many people and could probably shorten lots of mailing list discussions ;-).
These three would probably be very linux centric, but they belong to the typical requirements for a photography workflow.
- What to do with your photos
would be another topic. With this, I mean photo book and calendar making workflows with FLOSS, showing your photos online etc.
2 Likes
I started rt and I see all those possibilities. What I did not find is if rt can utilize these tools over your entire image library or if they are used just in the actual folder. That makes for me a difference in the workflow, since for the latter case you need an additional dam solution (if you need dam at all, but that’s another topic).
Sorry for being lazy and just adding 3 dots, from @patdavid’s post you see that I forgot some more 
. I guess such graphs may be useful to show which tools are available for the different workflows, but they may need a more polished appearance for a main page article. For prototyping, completing these dot files may anyway be useful.
Lol, sorry I was not trying to say you were lazy! It took me an hour or so to draw the graph I made. I put it on github so hopefully someone else would add to it, because I’m lazy. 
I had also been thinking maybe we could do some micro video tutorials and maybe curate the available tutorials on YouTube into a playlist or something similar.
1 Like
Ahhh, you all are fkn killing me! All these great ideas that I want to stop and work on like, right now!!! 
I think as soon as we have the main site on github and everyone will be able to start forking and working on things we’ll start really getting some awesome content published for folks!
1 Like
I would love to do video tutorials. Just have to find some quiet time.
1 Like
I’ve found that 11PM-2AM the kids stay quiet(er)… 
1 Like
This would also apply to LR users, new and experienced, that don’t want to pay the monthly fee for PS.
Wouldn’t those users normally migrate to something like darktable or RawTherapee first?
Not necessarily. There are a lot of photographers that primarily rely on LR and only use PS for clean up and more complex clone work. I believe it was even mentioned on the jpeg2RAW episode you did.
Maybe I misunderstood something? You said:
Which I assumed meant that the Shoot/Process JPG readers might also be Lr users, now and experienced. Did you mean that Lr users are possibly the target for JPG processing (vs. RT or dt)?
Not the shooting, of course. But certainly the JPG processing part. I’ve encountered quite a few new photographers who know next to nothing about PS and even less about GIMP. They got Lr because it was recommended to them by (insert photography YouTube guru of choice here) and would like to take advantage of the localized editing PS offers without having to subscribe to Adobe’s racket of a business model.
1 Like