Feature #9239

Upload styles to website in lighttable mode

Added by Robert Rosman over 7 years ago. Updated over 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
hardware architecture:


In order to get social about sharing darktable styles I think it must be easy to upload them, together with example images before/after. My proposal would be to add an "upload button" in the lighttable styles module. It would work like this:

  • Selecting a style and pressing upload would bring up a new dialog, if one representative image is selected (otherwise complain).
  • Ask for title (suggest the chosen name, but make it possible to change), description, author and email. Other data might be relevant. We could also look at login possibilities later on.
  • When user is done and want to upload, automatically generate four images: thumbnail-before, thumbnail-after, big-before and big-after. The size would be restricted to e.g. 200px for thumbails and 600px for big images.
  • Upload the style, images and metadata to the server.

This issue heavily relies on the platform in issue #8747.

I'm having some experience of c++ programming, so I might start hacking on this, unless someone stops me ;)

gdb.txt (187 KB) gdb.txt Simon Spannagel, 02/22/2013 01:13 AM
backtrace_dialog.txt (43.7 KB) backtrace_dialog.txt Robert Rosman, 03/02/2013 12:44 AM

Related issues

Related to website - Feature #8747: new sharing platform for dt stylesFixed12/08/2013

Related to darktable - Feature #9338: Add possibility to import more than one style at onceFixed04/03/2013

Has duplicate darktable - Feature #10607: Uploader/Browser for Lua Scripts and StylesNew08/13/2015


#1 Updated by Simon Spannagel over 7 years ago

  • % Done changed from 0 to 20
  • Status changed from New to Triaged

Hi Robert,

Sounds interesting to me! I haven't started thinking about the web platform, so you might be able to influence the whole thing. Concerning the integration into darktable itself it would probably be best to first plan (UI wise and code integration wise) and then discuss with more devs. This works best on IRC i guess, this ticket can then be used keeping track of the discussion and outcomes. This approach prevents you from frustration and rewriting code several times. :)


#2 Updated by Robert Rosman over 7 years ago

  • Assignee set to Robert Rosman

Thanks Simon for quick feedback!

I threw out some thoughts on the mailing list, but haven't got too much response yet, other than Tobias directing me to issue #8747. I'll begin with the platform itself first, but I'll discuss my plans before hacking away to much :)

#3 Updated by Robert Rosman over 7 years ago

I've forked off dt and implemented the basics for this feature. It's working to choose a style, an image, enter the information and upload the style to the server (currently for testing purpose). There are still a couple things to do, beside bug testing the code:

  • expose thumbnails correctly (see comments in _expose_thumbnail)
  • do export and upload as control jobs, so the user can do some other work while uploading style
  • use pwstorage for username and password
  • handle server error or user declined etc.
  • handle errors better in general
  • still very unstable, crashing dt from time to time
  • support for internationalized tokens like åäö (even if we only want english on the website I suppose)
  • wrap complete words in description, not breaking them apart
  • clean up the gui, (some random dtgtk_labels appearing, make background dark grey, etc.)
  • don't use hardcoded tmp dir, but find platform specific path
  • make it optional to save changes in name and description locally

The implementation can be found here:
Feel free to try out the code, comment it, fix a bug, come with feedback and further requests :)

#4 Updated by Simon Spannagel over 7 years ago

Hej Robert,

I played a bit with your upload module - and I like it very much. Some notes:

  • it might be convenient to just export the big previews on user side and crunch them on the server down to the small thumbnail size. This reduces the computing time needed.
  • For me the thumbs are not drawn in most cases, only after resizing the window. This happens both w/ and w/o dt_control_queue_redraw_widget(widget).
  • Changing the Style name for the uploaded style alters the local name, too. I wouldn't expect this to happen, I'd like to keep local names I think.
  • I have been able to crash dt by resizing the window, not consistently though. Backtrace attached.
  • Maybe some visual feedback about the upload process would be nice. Best thing would be to close the window and show the export background job as usually done.
  • It looks like right now we are using the iop internal names ("atrous") - it would be nice to use the UI-wise promoted names instead. Probably that would need a table of name allocation on the server side since those are not shipped in the xmps.


#5 Updated by Jérémy Rosen over 7 years ago

quick question... are styles guarded by DT version ? there might be risk of breaking a db when importing the wrong version...

#6 Updated by Robert Rosman over 7 years ago

@Simon, Thanks for the notes. You've certainly got a point with generating thumbs server side to reduce export time. I've implemented it since I like the idea. The only thing that's hurting a little is that the GD library is not as good as dt when it comes to image processing. This means that the thumbnails may be a little misleading in colors, contrast etc. but then again they're too small to make any big difference. The important thing is that the large images are accurate. I did compare two thumbnails side by side, one generated by dt and one by GD, and I could definitely spot differences, but probably not such a big deal as it may sound :)

I've noticed that there is a delay before the thumbnails are drawn, up to a few seconds, since the history is changed on both of them, leading to some computing time. Could that be the reason you didn't see the thumbnails even with dt_control_queue_redraw_widget(widget)?

I guess you're right about changing style name locally, giving them a temporary name would probably be better.

The visual feedback on export will probably be fixed if we make the export + upload a control job (if I understand the process correctly)

Displaying the iop internal names are probably a bad idea, especially since we're not even checking if the module is turned on or off, but your idea would make it better.

@Jeremy, I'm not sure how it's handle at the moment, but thanks for pointing that out, we don't want to break our databases!

#7 Updated by Robert Rosman over 7 years ago

Alright, I'd say I've implemented all suggestions above. They should be in the git repo by now.

There are two issues that really bugs me, and I'm not sure how to get rid of them, if someone do, please help me out here:

  • After the "upload style dialog" have been opened once (and closed by cancel or upload button), it's impossible for me to open it again. It makes dt crash when the "after image" thumbnail is rendered. The backtrace points to something inside the temperature module, but it could very well be something along the path I'm missing. (Backtrace attached)
  • When hitting upload, I'd like the dialog to close, and a dt_control_log() message to be shown. At least for me only the last message is displayed, once all export and upload stuff is done.

Other than those issues, I'm actually pretty satisfied :) A few small fixes in #8747 left to do (especially links to grid/previous/next style). And of course you may find a ton of bugs, then please let me know!

#8 Updated by Robert Rosman over 7 years ago

Exporting and uploading now happens in background. Pushed changes to git repo.

#9 Updated by Robert Rosman over 6 years ago

Rebased and made a pull request.

#10 Updated by Jesko N over 6 years ago

Hi, this one looks really promising to me! :)

As far as I understood you now calculate the previews serverside?! If so, what would you think about using a set of 5-10 different base images to show how the style affects different images.
Some styles e.g. look completely different on a black than on a white background (esp. if they use special blending modes or conditional masks) or differ depending on base colors, contrasts...

Users of the website could select the desired base image (thumbnail) first from a dropdown and would then see the precalculated preview for all styles applied to the selected base image.

Suggestions for base images would be:
  • Portrait with dark background
  • Portrait with light background
  • Greyish Background (e.g. Landscape Mountain, Dust)
  • Blue Background (e.g. Landscape Sea, Sky)
  • Colorful image (e.g. Party, Carnival)
  • Situations: Sports, Wedding, Animals...

What do you think?

This is also related to the discussion in #9715

#11 Updated by Robert Rosman over 6 years ago

Cool, thanks :)

The previews are calculated client-side, directly in darktable before uploading the style + preview images. I read the discussion in #9715, and I think you have a point that should be considered, I will add a comment to the discussion over there.

I see what you mean with having different kind of previews on predetermined images. Since the processing isn't done on the server, every darktable installation would have to include these images and the uploading times would increase.

I think a better approach would be to make it possible to upload several images of choice to each style. That way it's possible to show some different use cases. It would indeed be useful to see different styles applied to the same image, but I think it would be better to do so inside dt - see #9715.

#12 Updated by Roman Lebedev almost 5 years ago

  • Has duplicate Feature #10607: Uploader/Browser for Lua Scripts and Styles added

Also available in: Atom PDF

Go to top