I’ve recently published version 0.5.0 of DNGLab, a free open-source RAW to DNG converter, written in Rust.
A list of currently supported cameras is listed here: dnglab/SUPPORTED_CAMERAS.md at v0.5.0 · dnglab/dnglab · GitHub
This is a big milestone because all the usual file formats are supported now. There are still some TODOs on the list but it’s now usable for a wide range of users.
Feedback is welcome, if you find some bugs please raise an issue on github, thanks!
Oh my! Last time I checked DNGLab supported a couple of Canon cameras, now look what you’ve done! This is quite amazing. One of my pet peeves with Adobe DNG Converter has been that it can’t preserve time stamps of the original files. I’ll see if I can find it in DNGLab 
Thank you! Again, amazing!
really cool, congrats! i’d be interested in a vkdt input module using this to decode images. i haven’t done anything with rust before so that’ll require a fair bit of input from your side though… let me know if you’re up for it.
since you mention benchmarks in your changelog. how does it compare to rawspeed in terms of speed?
Hmm, not sure if dnglab works well with Nikon D7000 files.
This command:
$ dnglab convert DSC_6748.NEF DSC_6748.DNG
results in a pixelized image (fragment only):
EDIT. I downloaded dnglab_0.5.0_amd64.deb and used it on Xubuntu 20.04.4.
Interesting. Please open an issue and provide the raw file. I have not seen this problem during development. Thanks.
I’ve checked again all 5 raw samples on raw.pixls.us for D7000 and everything works fine. Can’t reproduce this. Which raw processor (darktable, RT, …) do you use?
Maybe it’s a bug that depends on the firmware… Anyway, if you can reproduce this please raise an issue at github providing a raw file and steps to reproduce, thanks.
I have a C API on my todo list for 0.6 or 0.7 release. Need to stabilize and clean up some internals before.
I’ve added benchmarks for some testing purpose and validate the tweaks I’ve done for LJPEG encoding (!), but I’ve not yet looked at performance for decoders.
I expect lower performance compared to rawspeed and libraw, as Rust guarantees you safe execution which comes at the cost of checks added by the compiler - which comes at cost of preventing vectorization. There are solutions to this but you have to check the asm output by hand if you have choosen the “right” solution, so I’ve done this only for “my” critical parts like LJPEG encoding.
This needs more time which I’m sure I will spend some day, but first prio was to add the functionality at least
Hello, I can’t upload a raw file on github, so I’ll do it here.
Attached as well a screenshot of the resulting dng (the real one is nearly 40MB, the raw under 20MB). I don’t understand your question about which raw processor I use, has nothing to do with dnglab, isn’t it?
DSC_7429.NEF (18.8 MB)
This looks like a compressed NEF…maybe this is the issue??
My camera gives me only two choices for NEF : lossless compression or compression. I always use lossless.
Hello, in Darktable the dng opens fine indeed. Apparently gThumb and Geeqie were showing the thumbnail instead of the dng, that’s why it was pixelized. I also tried to open the converted dng in ImageMagick, but that resulted in a warning '“Unknown field with tag XXX encountered”.
When opening the dng in HDRmerge and saving it as a new dng, it shows up fine in Geeqie and gThumb, but throws again a lot of warnings when opening in ImageMagick, in the end it just shows the thumbnail.
In Adobe DNG Converter there are two sizes of JPEG previews to chose from — medium and full size. Medium is 1024 pixels on the longest side. You can also chose not embed a preview.
Do you know if DNGLab puts the preview from the --dng-preview option in “the same place” as the “JPEG Preview” option in Adobe DNG Converter does, @cytrinox? The 1.6.0.0 spec says:
The highest-resolution and quality IFD should use NewSubFileType equal to 0. Reduced resolution (or quality) thumbnails or previews, if any, should use NewSubFileType equal to 1 (for a primary preview) or 10001.H (for an alternate preview). DNG recommends, but does not require, that the first IFD contain a low-resolution thumbnail, as described in the TIFF-EP specification.
Did you use --dng-thumbnail without --dng-preview when you encountered this problem @paulmatth?
Nope, just a straight dnglab convert X.NEF X.DNG
Indeed, it looks like a preview image. I was going to check for you but ran out of time. You could give it a try to see if it matches what you are getting.
DNG thumbnails and previews are RGB images, but dnglab is not a raw developer. I’ve implemented PPG demosaic and gamma curve for basic processing, but it’s far from a perfect worflow. So for now, if the original RAW contains a usable RGB preview image, I use this for the DNG thumbnail/preview. If no RGB image is embeded, I debayer the RAW data instead.
Adobe DNG generates both images by their own internal raw development pipeline. This has some benefits for RAWs that don’t have any embedded previews. On the other side, for newer formats like Canon CR3 (which contains a hi-res JPEG preview image) I re-use this for the the DNG preview, which is a benefit, too.
For older formats without (good) embedded previews, there is potential for improvments I will focus on later.
Could you also include some notes/code on how to install this new version from the source code. You have great notes on how to use it, once install, and can not wait to try this new version.
Excellent cytrinox. A couple of questions:
The reason for the last two is that some software (like Matlab) will throw an error with non-16bit or compressed raw DNGs. DNG converter behaves as requested with the -u switch.
Look forward to trying it.
Jack
What do you mean with camera specific info?
I put a copy of dnglab_linux_x64 into ./local/bin and can now access the .5 version of dnglab.
