Well there is Exif data in my dngs, darktable can read it, but vkdt and RT can’t.
I just tried some other photo apps for Android, apparently none of them creates dngs whose Exif can be read by RT or vkdt.
oh cool! i suppose that means you figured out how to move colours via rbf 
i have a local change that i forgot to push: limit the rbf to the spectral locus, so that messing with colours this way will never produce values outside the possible number ranges.
No I did not try it. I did this with the grad nd filter - just increased the blue.
yay, the current linux user features an article about vkdt (9 pages! only for the german speakers):
https://www.linux-community.de/magazine/linuxuser-ce/2022/03/
unfortunately it seems pdf of the community edition misses that article, so it’s paywalled. anyways happy to see this 
15 Likes
Congrats, Jo!
not that i know of. i suppose it’s a matter of compiling in the right flavour of rawspeed? i suppose my use of exiv2 is so scarce that it would probably not fail due to that.
if you want i can try and post instructions.
…in fact yes that’s all it takes (this is the R6 CR3 sample from raw.pixls.us):
cd ext/rawspeed
git remote add cytrinox https://github.com/cytrinox/rawspeed/tree/canon_cr3
git fetch --all
git checkout canon_cr3
cd ../../
rm -rf built/ext
cd bin
make -j20
…and it’s even slower than the CR2 decompressor was, it seems 
i also have this local diff
diff --git a/src/db/db.h b/src/db/db.h
index 665d924..b5311e6 100644
--- a/src/db/db.h
+++ b/src/db/db.h
@@ -118,6 +118,7 @@ dt_db_accept_filename(
const char *f2 = f + strlen(f);
while(f2 > f && *f2 != '.') f2--;
return !strcasecmp(f2, ".cr2") ||
+ !strcasecmp(f2, ".cr3") ||
!strcasecmp(f2, ".crw") ||
!strcasecmp(f2, ".nef") ||
!strcasecmp(f2, ".raw") ||
(and no i’m not proud about it) will push at some point, but need to run now.
I will try to mak use of omp for the RT version of the CR3 decompressor…
I think that CR3 PR has been abandon, as Roman said he’d need to rewrite it, but he hasn’t started rewriting it yet, which is why there is an in-tree version of libraw in darktable now.
i will not comment on the libraw thing.
the canon_cr3 branch i used above is 8 days old at the time of this writing.
that sounds great! not that i have a cr3 camera or the money to get one
but decoding this thing took 500ms (!!!) here. that’s like half a second! unacceptable!11
i remember some formats were easier to parallelise, for instance the fuji raws decode so much quicker. hoping the tile based wavelets in cr3 offer enough possibility for parallel processing. i’m sure if anyone can do then it’ll be you.
1 Like
One of the problems is, that the current version (though already using omp) only uses up to 4 cores. I’ll see what I can do.
this is now pushed. also i updated rawspeed to new upstream. it contains colour matrices so prospectively i can delete the adobe_coeff.h header. currently it’s still in use for some other things though (mlv, external tools) that need fixing.
note that for cr3 support you’d still need to compile in cytrinox’ branch, as in the listing above.