General thought about dt and what dt's audience is

Target user

enthusiast photographers that shoot in raw (if not, someone that knows why he doesn't shoot in raw) and has basic knowledge of PostProc notions or is ready to learn them (we can help in that regard, but we should not hide these notions)

Also professional photographer, that can get more from darktable using more advanced or esoteric plugins. Have into account that we ship every plugin in a package, but other programs as Lr only ships a very basic set and then users has to download more plugins if they want to have other tools.

terms the user is expected to know

  • white balance
  • color profile
  • raw
  • demosaicing? (not as long as we don't provide options there)
  • concepts like lightness/luminance and chrominance
  • metadata/EXIF
  • hsv color space

terms the user is not expected to know, but might learn through DT

  • split toning
  • bayer pattern
  • color management (not just profiles, but also rendering intent, ')
  • Lab color space
  • LCh color space

terms the user shouldn't need to know to use DT but that can go in usermanual with an explanation for those who want to know more...

  • Fourier transform (unused in dt anyways)
  • wavelet transform

expected technical knowledge of user

  • roughly knows how raw works
  • knows algorithm "what they do"
  • should not knows algorithm "how they work"
  • can learn by trial error in DT

what DT is/isn't

  • not a picasa like (one in all photo management which tries to avoid the user making decisions/keep him in predefined tracks)
  • not a photoshop like (i.e raw developement, not photo editing/drawing)
  • not a slideshow viewer
  • what about DAM? we do: filter/basic collection/tagging
  • auto-parameters are expected to give rough good values, not to avoid the user having to think (i.e no magicall enhancing "touch everything" plugins)
  • dt is a workflow tool (=> customizable plugins, common tasks should be fast)
  • shall basic file management be done in DT?
  • work together with other software to some degree (exchange XMP files, ') (important for "home user", as he will use shotwell for image library managing)

What part of DAM should/shouldn't DT do

* it should not do image display (slideshows) Slideshow integrated now

  • it should allow "first filtering" (selecting keep/no keep) on new imports
  • it should not do local modifications (only modifications on the whole image)
  • it should export tags/rating in a compatible way to digikam/shotwell (compatible xmp files)
  • DT is not expected to manage a lifetime of image. images should leave DT for another tool at some point (or is it? some people want to keep all their raws... should we have an "archived rolls" manager"?) => debatable To me the ability to have tags means that somehow dt is also there to let me organize, archive, and retrieve pictures forever... If import is fast enough, users might very well remove them from time to time and just add when needed. maybe we need a way to specify a folder on the command line
  • it should handle importing from removalbe media and cameras

suggestions how to streamline dt's gui

we don't want to duplicate code for the gui in simple/advanced modes, but increase positive user experience by making existing functionality more accessible.

unsorted dump

  • Output color profile - I would put it in "basic" not "color".
  • Input color profile - same as above.

-- I highly disagree: the input and output color profile primarily affect color, and thus should remain in the color category. That said, in most use cases you do not continously need to change the colorin/colorout parameters, so that's probably also no argument to have them in the basic category. But again, Henrik is working on something that might alleviate this problem.

--- doesn't "white balance" primarily affect color but is in "basic"? Morevoer, I often change "Color in" to switch between "enhanced" or "standard" matrix as people appear really red on my 30D pictures :) It seems to me that categorization is really more about taste than anything else, so the customizable category would be the best [OT]

---- White balance does affect color, so does basecurve. But in that train of though exposure should go in the correct category, and I'm quite shure nobody would want that. So yes some exceptions have been made. But I'm not convince about colorin/colorout, I use these plugins a huge deal while creating new enhanced color matrices, so I doubt few people actually used these plugins as much as me, still I think they should remain in the color category.

-- The current plugins are categorized for logical reasons, NOT for convenience, since convenience is relative, and logic is less so. In the future we may have a customizable category or slider pane, which you can build to your own hearts desire.

  • Having customizable categories/panes would also cater to convenience, why bother if it's so relative. I think there is a confusion between convenience as a subjective preference and convenience as a result of experience (meaning not having to learn new routines for purely theoretical reasons).

-- You're basically saying here is that we should abide by anything that Adobe/$VENDOR decides. The whole point of doing open source, is freeing oneself from that...

  • You can look at it that way if you wish but then you must include most of X including desktop, wm's, file managers and applications. I prefer to relate to an already acquired knowledge/experience in this area regardless of how it came into existence. It is THERE, one can not ignore it but can improve it. Also worth noting that commercial software is modeled and evolves based on user input/requirements in good part.
  • Case in point, there are certain routines one does as soon as he starts working on an image like exposure, white balance, profiling, etc.. The argument that one rarely touches input/output profiles and therefore they mustn't be in "basic" is false, unless one is a total beginner in taking pictures, in most cases one hardly touches exposure and/or white balance.
--- Whichever way you put this, the colorin/colorout plugins obviously fit in the color category, and putting them in basic would remain debatable. And again, Henrik is working on something that most likely will render this discussion moot.
  • Add a [X] for hiding plugins or an option to that effect when right-clicking on them. SInce the plugins icons are not very helpful as to which plugin they represent and one has to hover over all of them and read the tooltips to know which one to hide, the [X] is a more efficient solution. Maybe place it next to the "reset" button.

-- We already have lots of mini buttons in the plugin header bar, so adding another doesn't sound that good. Again in general the hide/unhide system is not designed/intended to be used on a continuous basis. It's mainly intended so you can hide plugins you rarely use. Not hide/unhide plugins your regularly use. For plugins that are regularly used you can collapse/expand them.

  • I can agree that another button may be too much but the hide/unhide a plugin is a real job given the fact that plugin icons are mostly decorative and that one has to hover over all of them and read the tool tip to find the one he wants to hide/unhide.
  • Clean the top panel : the top panel, containing the menu to views (light table, darkroom, printing, etc.) should be collapsible to maximize the picture area or converted to a drop-down menu in the right column. The contextual help for modules displayed here should appear on a hover card next to the cursor while typing F1 (universal help shortcut).
  • All the style settings should be extracted from the sourcecode to a GTK stylesheet in order to make Darktable themable. 3 UI templates should be proposed : light grey, medium grey, dark grey.
  • The dark room modules should be ordered in the same order they are applied in the pixel pipe.

keyboard shortcut wishes

  • ctrl-c to activate crop and rotate in dr mode?
    -- I would not take ctrl-c here since this is the common shortcut for "copy" and could confuse users
    -- How about using ctrl-o, same as in Shotwell?
  • ctrl-e to export the currently edited image in dr mode with the settings from lt mode?
    -- ctrl-shift-e to show a popup window with the export plugin? (like!)
  • ctrl-t to assign new tags to one or more selected images in a textbox with auto completion of existing tags
  • ctrl-m opens same textbox for one selected image to edit the given tags
    -- good idea to stick to standard keystrokes from shotwell
  • ctrl-c / ctrl-v in lighttable mode for copying tags/styles/markers/stacks/etc from one picture to another, after ctrl-c a dialog could show up where one can choose what to copy

Home/End/PgUp/PdDown or some equivalents for navigating lighttable in filemanager mode -
-- PgUp/PgDown to flip through images in both modes? (There's also an issue about that)

min/max/default values

please put annoying cases here! plugins should always produce a noticable and mostly good looking result by just switching them on, and they should not break if values are set to their min/max.

-- Amen, I think most plugins have reasonably sane default, maybe some of the newer plugin don't. If you have concrete cases where this happens, please open Trac tickets for each specific case.

this also includes which plugins are visible by default for a new installation and which group they belong to.
-- I should look which plugins are visible by default in a new installation. The plugins grouping should be fine.
-- I actually made some small adjustments to which plugins are visible by default, but this is pretty hard to get right...

  • Tonemapping should have a less dramatic preset. In my recent git version when enabled it shows up under "basic" tab, should be moved to "effect".
  • Exposure: if the sliders are kept, black should make the image black only at the end of the cursor.

-- Please do elaborate a bit on this, since it's not entirely clear what you're getting at

  • Adjusting the black slider is very sensitive, for that reason moving it a very small amount darkens/whitens the image almost completely. In practice one can adjust the black only using the arrows.

-- Aha, true, good one. The real problem is that the allowed range for the plugin is grossly overscaled, leading to an oversensitive slider.

missing/undescriptive tooltips

put annoying tooltips here (best with suggestions how to replace them)
  • tooltip in date-override on import is confusing at best

useless options

put a note here if you feel some particular option/slider/checkbutton should always be left
in its default position (or could be always calculated as an optimal value automatically)
and could therefore be removed from the gui.

-- Automatically calculating optimal values in imaging seems like a pipe dream :)

there are opinions, that alsmost each camera raw convertor processes the raw differently, hence it is hardly justifiable to use e.g. ICC profile from Canon DPP with dt. As a result, best solution is to create own icc profile with dt, which finally leads to a decision to remove "unbreak profile" plugin as being redundant...

-- True, but people will always keep on ask about wanting to use proprietary ICC files, even with suboptimal or unintended results. I build the enhanced color matrices to prevent people from having to deal with ICCs altogether, but obviously this has its limits.

  • I think the problem most users have with "unbreak profile" is the name, no one knows how to "unbrake" a profile.

-- Yeah it's not the most elegant name... The description is quite accurate, since it fixes "broken" profiles. But I can see where the confusion happens. "Adjust input profile" would imply the input profile is actually changed, which is completely false. We're open to suggestions how to call the plugin...

  • Input profile compensation? The thing is, I don't quite understand if the profile is "broken" in general or only in relation to DT. From what I remember reading somewhere this plugin "unbreaks" only a particular Nikon profile in which case it could be called "Nikon profile fix". That way even if the name is not the most descriptive it hints better to whom should use it?
  • White balance - could use a visual approach like "color correction", if it's possible. If sliders are the choice, "color in" and "color out" seem to do the same thing, one should be enough.

-- First off white balance has nothing to do with color in and color out. Second, the whole point of having a white balance plugin and a color correction plugin, is so you can use white balance to do correction, to make your image look "natural", and then use color correction to make it look "nice". This way you can separate correction to get a natural white balance in a clean fashion, which always helps in creating generally usable styles.

--- white balance with color visual approach sounds great to me. I think the so-called "color in" and "color out" were referring to the two sliders "Temperature in" and "temperature out" inside the White Balance plugin. I am all for removing one of them. I do not see why a visual approach of white balance competes with color correction being visual too... [OT]

  • I see things have been renamed in the latest git I got but the issue is the same: temperature in/temperature out do the same thing but in opposite directions (blue-yellow) and tint does red-green. So, why do we need 2 temperature sliders?

-- Silly me (about colorin/colorout) I'm actually not sure about that, both slider are indeed rarely used, so removing one might be an option.

  • in darkroom mode, the exposure plugin may be made redundant by moving its functionality to histogram (display +/- EV adjustment in top right; black point +/- in left top; allow small stepped adjustments by mouse scroll button and bigger stepped adjustments by tilting mouse scroll button left/right; display auto on/off button in the top middle and put the lights/black cut-off to settings).

-- Every plugin in the pipeline should always be represented by a plugin GUI, since that is the canonical way to change things, everything else is just extra (however nice it may be).

  • I'm wondering how far this canon thing can be pushed until it will start breaking things and prove the point that rules make sense only if they evolve? See the church, the condoms, Africa and HIV.

-- There is probably no bigger source of confusion in the world than inconsistency. Unless there is a really strong argument for exceptions we can look at it, I don't see any right now. "We'll cross that bridge when we come to it".

  • :-)
    -- how about moving the functionality and calling the plugin "Exposure/Histogram"?
  • Keyword Darktable|Format is useless. This information is in the image file anyway and doesn't need to be tagged - Collections by format would be useful!

hard to understand methaphors

e.g. 'film roll' versus 'folder' or 'collection' vs 'catalog', 'velvia' vs 'saturation', 'clarity' vs 'local contrast'.
  • or Keywords vs. Tags
  • What is a catalog?
  • What is a collection?

plugin names and control label texts

  • Relight - I would rename it "fill light" since this is what it does.

Usually tab names are nouns, not verbs.

  • I'd say whatever seems more explicit and/or what people are used to; common sense is a good guide.

Examples are 'metadata' (that's a geek term, should be 'info' or the
like), 'tagging' (could be 'tag' or 'tags') and most of the names of the
plugins in DT mode.

However, some tabs use verbs instead that then are combined with the
names of the widgets inside the tab to form a sentence conveying the action.

Examples are 'select' (should be 'selection'), 'selected image(s)'
(should be 'catalog'). Here it is doubly weird. In the 1st case the
sentence is correctly formed. E.g. 'select all' or 'select none'. It
breaks down with 'invert selection' (could be 'inverse') and 'select
film roll'.

In 'selected image(s)' this is done completely different. Here the tab
name is not repeated on the widget (good!, it shouldn't be repeated in
case of 'select').

Speaking of tabs: Because the typo is lowercase and same size and same
font and same color as widget labels, they are really not that easy to
make out.
I suggest to use a bold font at least and/or headline capitalization for
tab names to stand out more as different from the normal widget labels.
-- I think we already tried something like this in the past, it didn't look very good back then.

While we are at the topic, there was the idea to have the number of selected
images in the title of that module (see docs/TODO). This would require an
additional callback for modules with which they can supply some string.

Rotating is the 1st thing I do after import, so putting this 'where the
action is', namely on the images on the lighttable itself, makes a lot
of sense to me.

Speaking of which. DT has a weird mix of actions that modify the view,
selection and contents of the images in LT mode, all in the right column.

I.e. The 'select' tab alters selection, 'selected images(s) alters data,
not image data but the catalog itself. 'metadata' and 'tagging' both (!)
alter metadata of images, 'collect images' changes the view of the
catalog (why not 'collect image(s)' in sync with 'select image(s)'? --
I'd just call this 'collection') etc.

I'd put everything that changes the view of the catalog into the top and
bottom bars for starters. Maybe selection could go in there as well.

I also vote for a right mouse button menu that has all selection and
catalog- and styles management and rotation in it. And a few more useful
Here's a screenshot of the RMB menu LR shows in catalog (aka LT) mode:

should "unbreak profile" plugin remain in gui, it could be named "adjust input profile" with a tooltip "change gamma & linearity for weird input ICC profile"
-- As I've commented above, while "Adjust input profile" sounds nice, but it's a false description, a naming like that implies something is done to the input profile, which is false. "unbreak profile", preprocesses input data, so it can be processed using a "broken" input profile. I'm not happy either with "unbreak profile", but every alternative that has been suggested completely misrepresents what it really does.

not going to happen (jo)

  • write xmp someplace except next to the image (also this is non-gui)
  • Demosaic - it is under "basic" with no choice of algorithm so there's only one. Might as well put "demosaic edge threshold & match greens" in preferences.

-- Those are plugin related settings and thus by defition should be settable in the plugin UI. The preferences dialog should never be abused for plugin settings.
-- And more importantly "match green/green equibrilation" is camera specific. So turning it on application wide is silly.

would be solved by new UI with quick toolbar in bottom panel

  • Overexposure - right now it is a plugin under "color". I would integrate it into "exposure" and enable/disable it with a checkbox.

-- I have doubts this should even be displayed as a normal plugins, since it should never touch a resulting image. So maybe we could place this in the bottom or top bar?

  • Saturation - should have a plugin of its own to include all its variations ("velvia" and the one from "color correction"). I'd also prefer the color sliders used in "split toning" modified as needed. Any visual hint helps.

-- Henrik is working on something that might alleviate these wishes.

Also available in: PDF HTML TXT