Hello,
I'm executing `dcraw_emu` inside a Docker container that uses `node:23-alpine` and the latest version of LibRaw.
When I run LibRaw to convert a DNG file inside the container running locally, I get good results. However, when the container is running on Digital Ocean, my results look very different: there's a lot of data lost in the output TIFF file that causes the result to look way too bright.
This happens only to a specific DNG file that comes from a scanner operated by SilverFast software. Other DNG files work fine and look the same on both systems.
The only difference I can think of is that Digital Ocean uses AMD chips, and I'm testing on ARM (M1 on macOS). Could that be the issue, or could there be something else?
Please make sure you're using
Please make sure you're using same LibRaw version compiled with same options/compile flags (e.g. DNG SDK support) and with same run-time options
-- Alex Tutubalin @LibRaw LLC
Thank you for your quick
Thank you for your quick response, Alex.
I'm using
librav-0.21.3-r0
on both systems. Here's a screenshot of what I gathered (left is my Docker container running on Apple M1 laptop, right is a Docker container running on Digital Ocean instance): https://www.dropbox.com/scl/fi/umk20exovyygzs952ywfi/versions.png?rlkey=...Both systems run
-6 -o 1 -g 3.0 12.0 -r 1.0 1.0 2.2 1.0 -T /vol/test.dng
but the results are different.https://www.dropbox.com/scl/fi/axtohrmyfr2g903pxjvbk/small_compare.png?r... This is a screenshot of what the source DNG looks like when my macOS renders it as a file preview
test.dng
, the result I got with LibRaw locallyLOCAL test.dng.tiff
, and the result I got with LibRaw running on Digital Ocean Docker containerDO test.dng.tiff
. As you can see, the one rendered by DO looks off, even though, in general, there are no issues with the DO LibRaw app.If the original DNG would be helpful, I'll ask its owner and get back. Please let me know!
Is there anything else I should consider?
Here's detailed info about the DNG file:
Sorry, the docker stuff is
Sorry, the docker stuff is completely out of our scope.
Could you please compile LibRaw from source on the problematic system and try to reproduce the problem?
Also: it is pointless to discuss some problem with specific raw (dng) file without access to specific file (But if we can't reproduce the problem ourselves, we can't help either).
-- Alex Tutubalin @LibRaw LLC
Got the permission from the
Got the permission from the image author to share here: https://www.dropbox.com/scl/fo/ndnfk0xg4r56l6k1you97/AHeaZGEZ9_0Oq4RWZJE...
The file is pretty large, it's named
test.dng
.Downloaded, thank you (you
Downloaded, thank you (you may remove from Dropbox to not extra distribute the file).
(As expected) the file looks normal regardless of decoding path used (with or without Adobe DNG SDK). Not surprising for uncompressed 16-bit linear (3-channel) DNG: there are very few places where things can go wrong.
Could you please use LibRaw's 4channels sample to check if RAW decoding/unpacking is the same on both platforms. 4channels produces four monochrome tiff files (G.tiff, R.tiff, B.tiff, G2.tiff), one per channel.
G2 should be completely black. Other three should match and provide same checksum on two different systems.
It it is so: the problem is in postprocessing stage (LibRaw::dcraw_process), but first, it's worth making sure.
-- Alex Tutubalin @LibRaw LLC
I used the 4chennels tool
I used the 4chennels tool that comes with the APK package for both containers. The results look quite different!
https://www.dropbox.com/scl/fo/ndnfk0xg4r56l6k1you97/AHeaZGEZ9_0Oq4RWZJE...
Folder prefixed with LOCAL had its results made on my machine, and REMOTE was made on Digital Ocean.
OK, thanks.
OK, thanks.
Looks like byte order swapped in REMOTE sample.
I'll investigate the problem in depth tomorrow.
At a 1st glance: LibRaw::read_shorts does not work as expected.
It calls libraw_swab() if host byte order does not match file byte order (this is the case: MM/Motorola byte order in file and II/intel byte order on host).
Depending on compile flags, libraw_swab is implemented in two ways:
- own code if LIBRAW_OWN_SWAB defined on compile
- host (libc) swab() function overwise.
Is there any chance to know compile flags used on DO-docker?
-- Alex Tutubalin @LibRaw LLC
Checked with LIBRAW_OWN_SWAB
Checked with LIBRAW_OWN_SWAB defined (so, own LibRaw swab used): looks OK.
So the only suspect for now: host (libc) swab() function
Recompilation with LIBRAW_OWN_SWAB should solve the issue.
-- Alex Tutubalin @LibRaw LLC
Thank you for looking into
Thank you for looking into this for me, Alex! I will test and get back.
Alex, I'd like to confirm
Alex, I'd like to confirm that your suggestion worked and the issue is now fixed.
I used the following flags in my Docker container:
With code tagged 0.21.4 found in the GitHub repo, compiled with
make install
.Thank you!
That means that system swab()
That means that system swab() call is broken in this specific environment. A very strange story...
-- Alex Tutubalin @LibRaw LLC