Hi, I am using Octave to open and process raw Canon camera images, (CR2 files). Octave uses Graphicksmagicks libraries to open images, and Graphicksmagick in its turn uses dcraw to open
raw image files. I am running Octave 4.4.0 on a Linux Mint 19 system. While trying to make the Octave image import work, I downloaded Graphicksmagick-1.3.30 source and compiled with the following configure options: --with-quantum-depth=16 --enable-shared --disable-static --with-magick-plus-plus=yes --prefix=/usr ( as suggested here: https://wiki.octave.org/GraphicsMagick )
And after this it works fine to import 16 bit TIFF images, they become 16 bit objects in Octave. However, it does not work to import CR2 files, they become 8 bit objects in Octave.
From reading this: https://sourceforge.net/p/graphicsmagick/bugs/205/
I realized that I could view and change the options passed to dcraw in the delegates.mgk file.
In the installed file on my system ( /usr/lib/GraphicsMagick-1.3.30/config/delegates.mgk) the dcraw options looked like this:
<delegate decode="dcraw" command=""/usr/bin/dcraw" -c -w "%i" > "%o"" ><br="">
From the dcraw manpage it is clear that these options will not result in a 16 bit image. There are several options to create a 16 bit image, I tried adding the -4 option as this results in a linear 16 bit image that is suitable for the kind of processing I want to do in Octave. So after editing the dcraw options were:
<delegate decode="dcraw" command=""/usr/bin/dcraw" -c -w -4 "%i" > "%o"" ><br="">
And after this editing, the image import in Octave works as expected, the CR2 files gets imported as 16 bit objects.</delegate></delegate>
In my opinion it must be considered a bug in Graphicsmagick that a 16 bit parameter is not passed to dcraw when the configure option --with-quantum-depth=16 is used.
Regards
Ulf
As you noticed, the arguments used for dcraw may be adusted by editing the delegates.mgk file. When dcraw outputs 16-bit data (depending on version) it may skip some transformations such as gamma encoding or skip white balance processing so the output is not similar to the 8-bit data it outputs. There are many different versions of dcraw and they do not all support the same options or behave the same. For a fairly new dcraw I have here (v9.27), using -6 would produce output which is most similar to the default for 8-bit data. If we were to make -6 the default, there would be little penalty for Q8 users since the file can still be read. Unfortunately the -6 option only works with recent dcraw releases (not sure of when it was added) so if we put it in the delegates.mgk file by default then dcraw would fail entirely if dcraw is not a modern version. I can make the configure script test to see if the option is supported.
This issue is resolved by Mercurial changeset 15853:1c8134c0f191. The -6 option is added if QuantumDepth is greater than 8. This might option not be ideal for Octave power-users but it is best for normal users.