in short, the i-raw module now supports filenames of the form DSCF%04d.RAF (for instance) and will open a sequence of numbers as animation. this can be played back in the gui or exported to h265 video (via gui export or cli).
currently this requires some manual .cfg file editing (setting number of frames, initial frame number, frames per second, setting filename with %04d). if you’re into timelapses and give this a spin, let me know how it goes.
there is some code for this, yes. i should clean this up some. happy to discuss in more detail or take your input on how to best streamline it for certain use cases.
only the first two and last two lines are important for timelapses. i don’t really have images for this, so i’m only running it on a short burst of 10 frames (that’s the frames:10 line above). the result can be viewed like this:
will make the sequence go from exposure 0 (frame 0) to exposure 4 (frame 9). you can create such keyframes from the gui by stopping the animation (space or the stop button) at the desired frame, setting the values you’d like, hovering over the control, and pressing ‘k’.
running the resulting graph through the cli (the same can be achieved from gui export):
vkdt-cli -g ~/Pictures/20200702_teapot/timelapse.cfg --format o-ffmpeg --filename timelapse --output main
the current align module will align the full image, not only do a camera shake correction (i.e. the teapot would not be moving any more). so that’d require a new module.
ah good question. i don’t think the k for keyframe shortcut will work on the ui widget. i just tried to manually put keyframes of the crop module in the .cfg, which works “fine”. actually i think this should probably be done in a different transformation module that will never change the resolution of the output. animating output size sounds like asking for trouble (the current implementation kinda works nontheless but leaves black borders if you animate to crop smaller than frame 0 did). could be a switch in the c/r module i suppose.
quick diary entry. today: initial wacom pen/tablet support for drawn masks.
i added support for raster masks drawn with a stylus and pen pressure tied to opacity (so far). this was a bit of a journey because glfw does not yet support these pentablet events. luckily there is already a working pull request for it, so i just had to build this branch and publish it somewhere and then link vkdt against this and implement a few callbacks.
because of the non-std glfw (i hope the feature will make it to 3.4!), the vkdtcode sits in a branch and requires some manual tweaking to link against the correct glfw version.
in particular, i have the following in my bin/config.mk:
# use our custom glfw from git
VKDT_GLFW_CFLAGS=-I/home/XX/vc/ext/glfw/include/
VKDT_GLFW_LDFLAGS=/home/XX/vc/ext/glfw/build/src/libglfw3.a
which points to a checkout/build of said glfw version.
i suppose i’ll merge it to master with a compile time switch/detection whether glfw supports the callbacks soon, and hope stock glfw will ship pen support at some point.
could you run vkdt -d all to see if it maybe outputs another clue for me? like this and with the backtrace dumping not working it’s hard to guess what’s going on. if you didn’t even have gdb installed before i’m not going to ask you to try and run it manually
ps: wow, how these expensive high end quadros become mediocre over the years is incredible. on the other hand it’s been almost ten years…
/opt/vkdt/vkdt/bin~ ./vkdt -d all 127 ✘
[gui] glfwGetVersionString() : 3.3.6 X11 GLX EGL OSMesa clock_gettime evdev shared
[gui] monitor [0] DP-2 at 3840 0
[gui] monitor [1] DP-3 at 0 0
[gui] vk extension required by GLFW:
[gui] VK_KHR_surface
[gui] VK_KHR_xcb_surface
[qvk] dev 0: vendorid 0x10de
[qvk] dev 0: Quadro K2000
[qvk] max number of allocations -1
[qvk] max image allocation size 16384 x 16384
[qvk] max uniform buffer range 65536
[qvk] picked device 0 without ray tracing support
[qvk] num queue families: 2
[qvk] available surface formats:
[qvk] B8G8R8A8_UNORM
[qvk] B8G8R8A8_SRGB
[qvk] colour space: 0
[gui] no display profile file display.DP-2, using sRGB!
[gui] no display profile file display.DP-3, using sRGB!
[qvk] available surface formats:
[qvk] B8G8R8A8_UNORM
[qvk] B8G8R8A8_SRGB
[qvk] colour space: 0
[db] allocating 1024.0 MB for thumbnails
[qvk] error VK_ERROR_OUT_OF_DEVICE_MEMORY executing vkAllocateMemory(qvk.device, &mem_alloc_info, 0, &tn->vkmem)!
backtrace written to /tmp/vkdt-bt-2642.txt
The backtrace txt is as empty as before.
Sounds like my 2GB VRAM is not enough, right?
Actually I only bought the Quadro because it was the cheapest graphics card I could find that can drive my two 4k monitors when I wanted to sell my Vega 56 for three times as much as I bought it for. I didn’t expect the GPU shortage to last that long back then
planning to do the same for connectors and maybe for the global module description so you can see it in the ui when configuring the pipe/searching for additional modules.
thanks. yes that looks like a memory allocation problem. i think 4G is a good size to run vkdt, 2G suffers from my slightly happy memory buffers i keep for fast thumbnail generation. i suppose you might have success running ./vkdt /path/to/image/directly.raw, but even then i might allocate the full thumbnail machinery, just in case. i might need a “low memory” mode, but was hoping i wouldn’t have to do that.
alright, thanks for taking the time anyway. I don’t think it’s worth the time to implement a low memory mode. I’ll try again as soon as I can get my hands on a Ryzen 6000 Laptop (german)
ah good. let me know when/if you have this thing and whether vkdt runs on the amd. i’m not usually testing hardware other than nvidia so it’s quite possible that i’m breaking things.
Hey @qosch
Will keep an eye on your feedback, as I’m very tempted by the Zephyrus G14.
Any later input on using it with vkdt/linux/darktable will be precious as there is not much on AMD CPU+GPU laptops.
Gllm
so it’s quite possible that i’m breaking things.