work package list towards production use

[hanatos]

the following lists and prioritises a few key features that need work to make vkdt useful for production use.

this is currently work in progress and certainly not in any good order yet or complete. shout if you see changes needed.

DAM/lighttable

• :heavy_check_mark: history support for edits (.cfg)
  • potential addition: automatic graph diff/insertion of ab module to compare two history states
• history support for lighttable (vkdt.db)
• :heavy_check_mark: duplicate images in lt mode
• filtering and sorting ui needs a lot of ui love
  • maybe add sort by last edit/edited at all yet
• different presentation modes if useful?
  • more compact image only list
  • compare/select
• tags need some work (can assign and collect but not view the list of tags of an image)
• :heavy_check_mark: "files" view with basic copy-from-cf/sd-card functionality (so it'd be "files" "lighttable" "darkroom" "node editor" from generic to special)

image processing/darkroom

• :heavy_check_mark: quake to replace ancient space invaders game
• module versioning (for legacy_params as in dt or for versioned params and main.comp)
• related to that last point: backward compatibility guarantee (starting at version 1.0, say)
• :heavy_check_mark: full blown 2D node editor
• port essential processing modules
  • :heavy_check_mark: colour balance: see grade module
  • :heavy_check_mark: retouch see wavelet module
  • :heavy_check_mark: tone equaliser zones module
  • diffuse/sharpen?
  • grid/guides overlay for crop/rotate/perspective (can use dt_draw postscript interpreter)
  • :heavy_check_mark: postcard frame
  • :heavy_check_mark: automatic chromatic aberration correction/defringing ca module
  • :heavy_check_mark: contrast equaliser (eq wavelet with manual edge weight, threshold, and scale curves)
• super resolution/aligned hdr bracket
• :heavy_check_mark: rate/label in darkroom mode too

other/general

• scripting. lua or pybind11?
• metadata (via scripting language?) is currently pretty much not supported. minimal metadata we get from rawspeed.
• ui work
• :heavy_check_mark: export custom keybindings to make them persistent
• :heavy_check_mark: context sensitive ui help for keyboard + gamepad + mouse operations
• :heavy_check_mark: unify where is stuff (display profiles, default pipelines, fav ui, presets, etc): in ${HOME}/.config/vkdt or global bin/
• :heavy_check_mark: job scheduler for export in background (as well as copying in files view)

[trougnouf]

pybind11 means support for python and its deep learning libraries? Yes please!

[hanatos]

noted.

[aurelienpierre]

DAM/collections

• lighttable thumbnails view:
  • :heavy_check_mark: rating overlays
  • hint of whether the pic was already edited
  • contextual menu with:
    • move,
    • :heavy_check_mark: delete, [exists only in right panel]
    • rename,
    • check the integrity hash of the RAW,
    • find similar pictures in database
• image viewer/culling/validating:
  • way to display an arbitrary set of pictures next to each other to evaluate them
  • collage/masonry style or fixed-height (horizontal scrolling) carrousel view
• collecting pictures:
  • :heavy_check_mark: by "hardware" folder content,
  • :heavy_check_mark: by arbitrary collections (virtual sets of pictures that only live in database), [only by symlink on file system]
  • by metadata
• filtering pictures:
  • :heavy_check_mark: by rating,
  • :heavy_check_mark: by tags,
  • :heavy_check_mark: by date-time taken [never tried the filter, but sort works]
  • by imported/last edited/last exported
• importing pictures:
  • :heavy_check_mark: from folder (add to database, don't copy), [vkdt has no db]
  • from SD card/camera (list all pictures on SD card, regardless of the SD directories structure, copy, add to database),
  • :heavy_check_mark: from single image (add to database, open directly in edit mode),
  • check hash of origin/destination files after copy,
  • save the unique hash of the RAW file in database (for archival integrity checks later),
  • save a "similarity" hash or vector in database (to find similar images later)
• exporting pictures:
  • :heavy_check_mark: batch export to several containers (web low-res, web high-res, archive full-res, print full-res) from a single pipeline run, [core supports it, needs ui wiring/python script]
  • add/remove metadata (option to remove privacy data like GPS, add authorship for stock archive photographers, etc.),
  • save the path to the exported files and an unique hash in database.
• auto-DAM features (AI):
  • extract the main colors (K-Mean) in the pictures and auto-label,
  • identify the content and people (-> training set) of the pictures and auto-tag.

[aurelienpierre]

Image processing pipeline

• merge RAWs for exposure bracketing (HDR),
• :heavy_check_mark: merge RAWs for noise averaging, [with alignment. works best for small movements etc]
• :heavy_check_mark: interpolate WB and exposure for timelapses, [there's keyframe support on pretty much all params]
• merge RAWs with slight parallax offset for super-resolution demosaicing improvement,
• :heavy_check_mark: compose RAWs into each others ("load image" node) [just add multiple i-raw and blend modules or so]
• define a pipeline-wise white level (scene-referred / HDR white needed by some algos to normalise powf, for example)

[hanatos]

..updated the list on top with a few of the suggestions.

as to auto-DAM/AI stuff: i'll avoid (past) hype train vocabulary :) and also darktable had a similar images search in the past and it was removed because nobody was using the feature. i think this is one of the features (maybe like timeline histogram) which is super cool if you see it first but gets boring quickly and does not really support everyday workflows at all.

as to hashes in databases: vkdt does not have a database (cf. bloatware). it works on directories and files on your harddrive. there is an option to delete selected images which i find useful because only once you worked on the image you can judge whether it's rubbish (not from the jpg thumb in your average file manager).

i do see a use case for sloppy/half way imports from CF/SD card and the value of software telling you that in fact these few images you already copied, but the others not yet. might think of a lightweight way of supporting this feature (probably similar the export, though i'm less sure about that case).

[aurelienpierre]

as to hashes in databases: vkdt does not have a database (cf. bloatware). it works on directories and files on your harddrive. there is an option to delete selected images which i find useful because only once you worked on the image you can judge whether it's rubbish (not from the jpg thumb in your average file manager).

I have had RAW pictures that did not survive 2 HDD copies and are now unlegible. The purpose of hashes is just reliability in long-time conservation. I was told that it is a concern too for humanities faculties, for collections of images that have scientific value and would benefit from periodic integrity checks (and maybe map it with backup restoration or something later). It can just go in the params file if there is no DB.

Regarding DAM, I'm more and more leaning toward a second app, compatible but self-enclosed, and possibly communicating with other apps through XMP. The reason is that no DAM app will please everyone, and some dt users already use Digikam or Rapid Photo Downloader for DAM in a non-efficient way. Making DAM strictly separated from the processing would allow third-party file managers that would just interface the same way, and improve interoperability with other RAW and raster processors.

as to auto-DAM/AI stuff: i'll avoid (past) hype train vocabulary :) and also darktable had a similar images search in the past and it was removed because nobody was using the feature. i think this is one of the features (maybe like timeline histogram) which is super cool if you see it first but gets boring quickly and does not really support everyday workflows at all.

It also happens that features are not used because GUI doesn't invite to using them, or doesn't advertise their existence. Tagging manually is very boring.

[hanatos]

yes, archival and extended database capability with multi-million images and their textual representations on a redundant cluster for async multi-million user access.. please let's have that in an outside application ;)

i do however support simple streamlined workflows that just require the occasional tag or filtering capability to get a specific job done. or rather: support a typical session from import to export, with everything that is normally needed in one application (workflow).

i'm thinking maybe some basic copy-from-sd-card could be part of this (though i don't want to link against dinosaurs for this), and so is assigning quick tags to collect images from multiple folders for a specific project.

the parameters (.cfg with graph configuration and uniforms for the glsl kernels) are strictly for non-gui non-dam image processing only. let's keep concerns separated as well as we can this time. labels and star ratings as well as filtering settings for a folder go into the vkdt.db text file. this would be the place for file integrity hashes and tags and the like.

[aurelienpierre]

yes, archival and extended database capability with multi-million images and their textual representations on a redundant cluster for async multi-million user access.. please let's have that in an outside application ;)

Of course, but that's what I'm saying. Just collect and store the data in this app and make it easily read/write-able for third-party scripts and apps that cover specialized uses. Current dt is not modular & transparent like this so we have a zillion options to try and cover all use cases. Making it easy for third-party to scratch vkdt DAM entirely and replace it with something else while still being able to connect seamlessly with darkroom/pipeline would avoid the need to support everything in the same monolith and be unable to optimize it for one defined use case deemed "typical".

labels and star ratings as well as filtering settings for a folder go into the vkdt.db text file. this would be the place for file integrity hashes and tags and the like.

Makes sense.

[hanatos]

Of course, but that's what I'm saying

yes, i didn't mean to disagree in that point. i guess i'm saying i'm willing to put in some support for very basic tagging and file importing etc in order to support a front-to-back workflow, starting with basic import and going all the way to basic creation of named collections for projects that span multiple jobs/folders. i think for most of these features there's a sweet spot where you can arrive at 90%+ of the functionality by using only 5% of the lines of code/maintenance burden/overengineering level.

will have to think about interoperability. it's probably a good idea to have standard xmp import/export (dublin core, say). i don't think going full xmp as we had done it in darktable did any good. just raised expectations of compatibility and then in reality things aren't this simple. of course really seamless integration into another application (using their main routine) is usually a lot of work on its own. probably made somewhat simpler by the relatively quick startup times that vkdt has now.

[phweyland]

Don't know if this is the right place to give opinion. If not, please let me know.

About tags, I have no production goal and therefore my preferences are different. If I understand properly, the plan is even less than the tags I've found in dt 2.3 when I started to play with it. It was supporting hierarchical tags but with a more than basic ui. With less than 8 characters, hierarchical tags are not really possible. It may be hopeless to see the feature extended externally if the core doesn't support it. This would be a bit disappointing for me.

The control of the metadata you want to include in your output projects' images is something where dt works correctly I think. But there must still be metadata to share of course.

About xmp, if you exclude the development data, the tags (no permanent tags) and keep only stars and colors, that should stay simple. In dt I see more issues on exif data which seem to turn more and more maker specific.

seamless integration into another application (using their main routine)

I don't understand this statement. What do you consider there ?

[hanatos]

Don't know if this is the right place to give opinion. If not, please let me know.

not a lot of noise here, so anything works :)

About tags, I have no production goal and therefore my preferences are different.

wait what? but you do have a use case in mind, no? i don't want to implement weight/complex features just so we have them. if you are actually using tags for some specific workflow/to solve an actual photography task feel free to open a separate issue and describe how such a typical session would proceed. that way we can see which features are actually required to solve the task.

as i said, i'm not into textual archival.. i always found hierarchical tags overly complicated, messy to work with (fill the list with the hierarchy and all the individual levels + all hierarchical recombinations..), and absolutely unnecessary for photography.

exif/xmp: to put that into perspective: vkdt does only optionally link against libexiv2, all necessary metadata comes from rawspeed. there is currently absolutely no metadata handling anywhere and to tell the truth it's another feature i don't miss. again, i'm open to support specific workflows that require this kind of data, but i'm not willing to include the feature just because and then end up with a complicated implementation, depending on heavy 3rd party libraries, that is rarely used and only half working.

re: integration with other DAM tools: that is about aurelien's idea to completely outsource the DAM to specific software that is dedicated to this task (digikam, say). the stars and labels are stored in a plain text file now (specific to each folder), so it's very easy to convert between that and xmp in an external tool (shellscript even).

[phweyland]

all necessary metadata comes from rawspeed

Great! Fine, Exif is out in that case.

if you are actually using tags for some specific workflow/to solve an actual photography task

I do use hierarchical tags along with my photography tasks. I guess other people will find this is not an actual photography task... But currently I'm happy to be able to do that inside dt, on lighttable, without having to switch to another DAM whatever. I can filter my images on these tags and, even more importantly, when exporting I can include (or not) the metadata (exif, xmp, iptc) I want based on these tags (country, location,..., author, and other images' descriptors).

feel free to open a separate issue and describe how such a typical session would proceed

Thanks, I'll do it.

[phweyland]

Thinking, ... lighttable is where the workflows can meet or diverge ... What about the possibility to launch vkdt darkroom as a [kind of] standalone executable for a single image (without reading the db, etc...) ? If it was possible, based on some specific workflows, the lighttable could be cloned / tweaked / changed, or even evolve to DAM, without losing the core benefits of vkdt. For export (and thumbnails...), there is already vkdt-cli which should work seamlessly.

[hanatos]

i consider this generally done. the tool works just fine for some production use cases. outstanding issues are probably better kept in more focussed tickets.