Incorrect behaviour of types.dt_lua_tag_t.#
types.dt_lua_tag_tby a numbered index (e.g.
types.dt_lua_tag_t) actually returns the images that have that tag attached to them, according to documentation. But there seems to be an indexing bug:
- accessing the first value (
types.dt_lua_tag_t) crashes the application
- accessing the second value (
types.dt_lua_tag_t) returns the first image
- accessing the third value (
types.dt_lua_tag_t) returns the second image, etc.
- the length operator (
#types.dt_lua_tag_t) returns the number of images attached with that tag plus 1
#3 Updated by Christian G about 1 month ago
I did some further tests. Since I also observed problems using
ipairs() on values of type
types.dt_lua_tag_t before, I tried this again with your example script. I changed lines 18 - 21 from
for i = 1, #test_tag do dt.print_log("image is " .. test_tag[i].filename) -- do end
for _,image in ipairs(test_tag) do dt.print_log("image is " .. image.filename) -- do end
This leads to the following error:
LUA ERROR : incorrect index in database
Is this expected? I actually expected to iterate over each image tagged with
And second, does this behaviour maybe have something to do with the described bug above?
#4 Updated by Christian G 9 days ago
I could further isolate the error case stated in the ticket description. I have imported some images into darktable, which contained tags as jpg file meta information, which are converted into darktable tags. When applying tag_index_test.lua on one of these imported tags (I only changed line 15 to the name of that tag), the behaviour from the ticket description could be reproduced. After entering the loop in line 18 with
i = 1 accessing
test_tag crashed darktable.
So the bug is maybe related to imported tags only, i.e. tags imported from file meta information.
On the other hand the error "
incorrect index in database", when using
ipairs(), is strange as well.