First, thanks for creating this version of DCRaw. I have been using the original DCRAW as part of a utility I have developed to make it easy to run the NIK Collection standalone. One of the added features is the ability to input RAW files. I needed a way to support Fuji X compressed files and this is probably the best and easiest way to do that. It also seems to be quicker than the original DCRaw.
I use DCRaw (and tried DCraw_emu) by starting it from my program passing command line parms. I was using a brightness setting (-b) of 1 for all my test files (from various cameras / manufacturers) and that seemed to work fine (using the original DCRaw). I used a Fuji X compressed file as input to DCRaw_emu and with the setting of -b 1 it came out very dark. I had to set it to -b 12 to get to an acceptable level of brightness. I tried a few other files and I had the same issue but not to the same extent. For a Canon CR2 file (also mentioned in another recent post) I found that I had to set it to -b 2.3 to get the right brightness. I tried that same setting with a Nikon .nef file and that one came out too dark. It was convenient to use a single standard setting for all types of files. Can this be changed in DCRaw_emu to work the same way as DCRaw?
The command line parms used were:
-v -H 0 -T -w -g 2.4 12.92 -q 2 -b 2.3 -4
Once again, thanks for developing and supporting this version of DCRaw. I hope to be able to change my program to use it very soon (hopefully after this issue is addressed).
Chris
LibRaw contains 'automatic
LibRaw contains 'automatic adjust maximum' code to not get 'pink clouds' problem when maximum data level reported by camera is higher than real data maximum (this is common problem with canon files esp. if intermediate iso are used).
To disable this feature use -c 0 option of dcraw_emu (imgdata.params.adjust_maximum_thr = 0 if you use LibRaw directly from your code, not dcraw_emu.exe)
-- Alex Tutubalin @LibRaw LLC
Using -c 0 did not have any impact
Hi Alex,
Thank you for the quick reply. I tried it with -c 0. I had the brightness set to 2.3 (leaving it at 1 made everything too dark). I did not see any difference using -c 0. Some images came out darker than the result from DCRaw 9.27, some came out lighter and one came out very similar. Obviously, changing the brightness level would change which was most similar. For most files, the version from DCRaw 9.27 (with brightness set to 1) was pretty consistent with the brightness level of the embedded JPEG from the RAW files (the version from DCRaw_emu was not).
Any other thoughts? I'd really like to use your version because of its other benefits but this complicates it.
NOTE: I did not see - c mentioned in your documentation. In the DCRAW 9.27 documentation, it says that -c is used to: "Write decoded images or thumbnails to standard output."
Chris
Developer of RNS (Run Nik Collection Standalone)
-с is, indeed, documented:
-с is, indeed, documented: https://www.libraw.org/docs/Samples-LibRaw.html
-c float-value
This key sets params.adjust_maximum_thr parameter.
Use -c 0 to completely disable automatic maximum calculation.
Default value: 0.75
Could you please provide some samples to test against dcraw/dcraw_emu. With -c 0 it should be the same, at least with default settings.
-- Alex Tutubalin @LibRaw LLC
Follow-Up on DCRaw_emu conversions
Hi Alex,
First of all, this specific problem was my own doing. I was using the -4 DCRaw parm that apparently does create some issues. Some of the files that I compared with had been converted without that parm. When I removed that, DCRaw_emu worked the way I had hoped and in a very similar way to DCRaw 9.27 (but faster).
There are still a couple of small differences from DCRaw 9.27:
* Fuji X files - these are coming out with the green a sort of yellow-green. This is different from the result with DCRAW 9.27 and different from the embedded JPEG.
* The resulting file name when I convert to a Tiff file is in the format filename.raf.tiff instead of filename.tiff
Otherwise, DCRaw_emu seems to do what I need it to do.
Chris
PS: I looked on the Data Structures page for -c so that's why I couldn't find it.
Chris
Developer of RNS (Run Nik Collection Standalone)
dcraw's -4 option results in
dcraw's -4 option results in
- linear gamma (-g 1 1)
- no automatic brigtening (-W)
- 16 bit output (-6)
There is no -4 option for dcraw_emu, but you may use -g 1 1 -W -6 instead.
Fuji X: what exact camera and what Libraw version?
.rawext.tiff - yes, this is intended option to allow convert filename.cr2 and filename.dng in the same folder.
-- Alex Tutubalin @LibRaw LLC
Fuji X color
The sample file in question was created with my X-E2 camera. I uploaded some screenshots and a copy of the file. The converted files are both a bit brighter than the embedded JPEG because I used a brightness of 1.
Link
Chris
Developer of RNS (Run Nik Collection Standalone)
Sorry, your link allows only
Sorry, your link allows only download of screeenshot_embedded_JPEG.JPG, no RAW to play with
-- Alex Tutubalin @LibRaw LLC
RAF File
Here is another link directly to the file:
https://1drv.ms/u/s!AhvHWo83K_oNjxRpT9I4Xzo00Z1X
Chris
Developer of RNS (Run Nik Collection Standalone)
Thanks.
Thanks.
dcraw processed file (with -w to get camera balance) is definitely more green.
We'll investigate the difference.
-- Alex Tutubalin @LibRaw LLC
The difference is in camera
The difference is in camera color profiles used in LibRaw and dcraw.
To get the same color as in dcraw, please go to adobe_coeff() function in (LibRaw)/internal/dcraw_common.cpp
and replace our color profile (two lines:
{ "Fujifilm X-E2", 0, 0,
{ 12066,-5927,-367,-1969,9878,1503,-721,2034,5453 } },
to dcraw.c profile:
{ "Fujifilm X-E2", 0, 0,
{ 8458,-2451,-855,-4597,12447,2407,-1475,2482,6526 } },
Than re-compile/rebuild libraw/dcraw_emu
-- Alex Tutubalin @LibRaw LLC
Color Difference
Since I'm using dcraw_emu, I can't use that solution. If the intent with dcraw_emu was to keep it consistent with dcraw, wouldn't it make sense to use that (revised) profile in dcraw_emu?
Chris
Developer of RNS (Run Nik Collection Standalone)
dcraw.c has not changed for
dcraw.c has not changed for more than one year now (also, may-2016 change was minor, so real freeze is about 2 years).
Because of that, maintaining full dcraw.c compatibility is obsolete goal :)
Meanwhile, for cameras supported in (last) dcraw.c we (very likely) will change color profile to dcraw's even if we think our profile is better.
-- Alex Tutubalin @LibRaw LLC
Color Profile
If that means that an upcoming version of dcraw_emu will use the dcraw color profile(s) that would be really good. Mainly, I just need the colors to match up with the colors in the embedded JPEGs. So far that seems to be the case, except for this one example.
Chris
Developer of RNS (Run Nik Collection Standalone)
> I just need the colors to
> I just need the colors to match up with the colors in the embedded JPEGs. So far that seems to be the case
Ummm.... "Match" means, in a very relaxed environment, "within maximum of 4..6 dE".
--
Iliah Borg
To match JPEG colors you need
To match JPEG colors you need not dcraw.c color profiles, but profiles used by camera vendors for in-camera processing (unavailable in most cases).
Also, the main problem is to repeat vendor's tone/contrast curve (which, in turn, changes when photographer change camera contrast/saturation/color mode) to match midtone brightness and highlights compression.
So, if your target is 'embedded JPEG match', than you (very likely) need own RAW postprocessing code instead of LibRaw::dcraw_process()
-- Alex Tutubalin @LibRaw LLC
I'm sorry I do not understand
I'm sorry I do not understand why you can't use this solution? On a side note, why use colour processing from dcraw at all, why not to use quality colour transforms, since you develop anyway?
--
Iliah Borg
dcraw_emu X-E2 color
Hi Iliah,
I am using dcraw_emu (as I used dcraw 9.27 previously) as a simple tool to convert a raw file to a tiff. I'm trying to keep it very simple and use existing tools created by people such as yourself who are experts in many of these things. My program acts as a controller and uses these existing tools (such as dcraw_emu) to perform specific tasks. I'm not a C programmer and thus I don't have the ability to rebuild a custom version of dcraw_emu.
My need is simple: I just need dcraw_emu to create tiff files that are good quality (color-accurate) versions of the image that was captured in the raw file. The result should be quite similar to the original embedded JPEG and to the results produced by other raw converters. In almost all cases, dcraw_emu is doing that. The greens in my X-E2 sample pictures seem to be an exception.
As a further comparison, I converted my sample file with Lightroom and with Affinity Photo (I can provide samples if you wish). The result was:
* The original embedded JPEG and the tiff file produced by dcraw 9.27 were the brightest green (almost the same).
* The version produced by Lightroom was close to the embedded JPEG but the greens weren't quite as bright.
* The Affinity Photo version was quite a bit yellower than the previous versions. I don't think that it provided a very accurate version of the greens.
* The Dcraw_emu version came out similar to the Affinity Photo version (but lighter). Converting it with the brightness turned down further might produce a very similar version to Affinity Photo.
Going back to the dcraw 9.27 color profiles could be an unnecessary step backward. In my testing of the Sony ARW files, I found that the version produced by dcraw_emu has more accurate colors than the dcraw 9.27 version (which was much yellower). Thus, for my purposes, a small change to the color profile for the X-E2 (and the other X cameras if they are the same) should give me everything that I need from dcraw_emu.
Chris
Developer of RNS (Run Nik Collection Standalone)
Thank you for the explanation
Thank you for the explanation, and we hear you. It is just that the word "accurate" is not the one I would use.
--
Iliah Borg