RawDigger 1.0.x complains and bug reports

Submitted by lexa on

Forums: 

This forum topic is for 1.0.x discussion and bug reports

Registration oddness.

Submitted by Guy Parsons (not verified) on

Paid $13.32 for Exposure Edition, downloaded, installed and entered (I thought) the registration number provided. When restarting some time later it indicates that I have a 30 day trial and seems to be ignoring the registration number. What did I do wrong?
Thanks and regards..... Guy

Activation - was my problem

Submitted by Guy Parsons (not verified) on

Like I expected, I did it wrong.... Sigh.
It was my cut and paste error and the license number was not being recognised hence no ability to activate.
Cut and pasted license much more carefully and now is all OK.
Thanks for quick response, now very happy, but looking stupid.
Regards...... Guy

Error while receiving activation code

Submitted by Bill Lealman (not verified) on

Order ID:3BC3E9Q-B3PR9W
After entering activation code and clicking activate, a message appears
"Error while receiving activation code
Please contact LibRaw LLC"
How can I activate.
Thanks
Bill

Dear Sir,

Submitted by Iliah Borg on

Dear Sir,

We hope the issue is resolved and the program is now activated.

--
Best regards,
Iliah Borg

Save samples in Research Edition brings error massage

Submitted by Johannes Leitner (not verified) on

Hello , I have licensed the research edition. When I try to save samples to a CSV-File, an error window with the message "White Balance checked, but White Balance Cell is not set. Select WB Cell in Data Transformation settings, or disable White Balance." is displayed and I cannot save the samples to a file.
Due to the research edition all fields in the "Data transformations"-Block are greyed out.
How can I clear the White Balance-Checkbox ?

kind regards
Johannes

Thanks for your report, this

Submitted by lexa on

Thanks for your report, this is definitely a bug, sorry.
Solutions (before fixed in program)
 Windows:
   download this Windows Registry file: https://www.dropbox.com/s/n67n19d6d6qcrar/removeExportWB.reg
   Double click on it to disable WB apply on export (Windows will ask twice about your permission)

Mac: In terminal window run this command:
defaults write com.libraw-llc.RawDigger Preferences.dnDoWhiteBalance 0

Sorry for delayed answer.

SD9 histogram and CSV incorrect

Submitted by Ted Cossins xpatUSA (not verified) on

Reference Version 1.0.2 build 279 Research Edition (activated)

Histogram and CSV export are incorrect

Histogram hard limits at value below max raw data in main window, see my thread here:

http://www.dpreview.com/forums/thread/3613960

Iliah is aware and has the raw file shown there.

Last line of a selection CSV export from another file also shows hard limiting:

4088,"4095","0.99718","0.99965","0","0","10"

SD10 files show correct values.

Hopefully Iliah is still investigating, posting here for better communication than through DPR.

Ted (xpatUSA)

Main Window info line - Sigma SD10

Submitted by Ted Cossins xpatUSA (not verified) on

While reviewing a series of SD10 IR images taken at ever-increasing shutter speed, I noticed that the indicated shutter speed did not change much, for example camera 1/80 sec was indicated as 1/37 sec. For the same images, Sigma Photo Pro showed the camera as-selected shutter speed.

A dump of the image gives:

CMbM:CaptureExpTime
Type=3 (float), Dimensions=1 (D0) (1)
M[0]=27030

CMbM:CaptureExpComp
Type=3 (float), Dimensions=1 (D0) (1)

And the relevant properties were:

SHUTTER:0.012048
SH_DESC:1/80
FLASH:OFF
PMODE:M
EXPNET:-3

M[0]=-3

CMbM:CaptureShutter
Type=3 (float), Dimensions=1 (D0) (1)
M[0]=0.012048

have not tested the SD9 in this regard.

Thanks,

Ted (xpatUSA).

Thanks for report.

Submitted by lexa on

Thanks for report.

Unfortunately, no SD9 camera on hand. Could you please provide two samples with different shutter speed?

Fixed in LibRaw.

Submitted by lexa on

Fixed in LibRaw.

The fix will be included in RawDigger 1.0.5. I can send you beta (internal) version if you need it ASAP.

Shutter speed indication SD9/SD10

Submitted by Ted Cossins xpatUSA (not verified) on

Thanks, no need to send the beta version, I'll wait for the stable release.

Ted

No batch processing

Submitted by Nick (not verified) on

I'm trying to process hundreds of files into TIFFs for a time lapse with a Sigma DP1m. The single image output is great but its too slow doing it one by one by hand. I've tried DCRaw but it gave me garbage output, no image. My only option now is set up a keyboard macro.

For now you may use Ctrl

Submitted by lexa on

For now you may use Ctrl-right arrow to go to next file and Ctrl-E to run export dialog.
Batch processing is definitely planned, but no exact schedule.

Program won't work

Submitted by Chris Noble (not verified) on

I'm running Windows 7-64bit. I'm able to open the program (1.0.4), but as soon as I try to load an .RW2 file (from my Lumix G5), I get a Windows window: "Rawdigger has stopped working". What should I do?

X-Trans DNG - scrambled pixel layout in RawDigger

Submitted by Steve Sprengel (not verified) on

An Fujifilm X100S RAF seems ok in Adobe Camera Raw and RawDigger.

A DNG created from the X100S RAF is ok in ACR but shows scrambled pixels in RawDigger.

This suggests RawDigger is misinterpreting something in the DNG that specifies the photosite pixel layout.

Here is a screenshot of what I see in RawDigger:
https://www.dropbox.com/s/3qmtpfldwq8u90e/2014-03-06_183027.png

The RAF file came from here:
http://img.photographyblog.com/reviews/fujifilm_x100s/sample_images/fuji...

A copy of the converted DNG is here:
https://www.dropbox.com/s/8ld9mg5y1wai4re/fujifilm_x100s_18.zip

The DNG Converters I used can be downloaded from here:
http://www.adobe.com/downloads/updates

and here:
http://labs.adobe.com/

I have tested with RawDigger 1.0.4 and 1.0.5, and the Adobe DNG Converter 8.3 and 8.4 RC with the same results.

X-Trans DNG - scrambled pixel layout in RawDigger

Submitted by Steve Sprengel (not verified) on

The X-Trans pixel scrambling seems to be fixed in 1.0.6; however, there is a problem with the Black Level computation and/or usage:

When I open the RAF, linked below, in RGB Composite, the Black Level seems to be computed/used correctly amongst Auto (1023), Manual (1023), Channels (1023, 1023, 1023, 0) and the target remains gray. The final 0 in Channels corresponding to the second green channel, is disabled due to an X-Trans not having two independent green channels (apparently).

If I open the corresponding DNG from that RAF, the Auto option works ok (displays a gray target) with Black Level values of (1024, 0, 0), but if I use the Channels version with those same three numbers plus a zero for the disabled second green channel (1024, 0, 0, 0) then the target is too green. Also, with the Manual (341) option displays too red. If I change the Channel BL balance values to (1024, 1024, 1024, 0) then the target is neutral colored.

That suggests the Auto BL values that are reported and filled into the other BL areas are wrong, and should probably be either the same (1023, 1023, 1023, 0) as the RAF has or at least the first three numbers need to be the same.

Maybe the pixel layout is unscrambled for display but the BL computations are still working off the scrambled pixels?

RAF: https://www.dropbox.com/s/g666ewq13hofnd0/X100ShVFAB.RAF
DNG: https://www.dropbox.com/s/pcjowu687dlbhpm/X100ShVFAB.dng

This is due of inconsistency

Submitted by lexa on

This is due of inconsistency of DNG (Adobe Converter).

For 6x6 CFA pattern RawDigger expects 6x6 BlackLevelRepeatDim tag (or per channel value).
In your DNG samples 1x1 BlackLevelRepeatDim is provided, so interpreted as Red BL is 1023 and others is unset (so zero).

Looks like we need special case for that.

X Trans DNGs vs RawDigger

Submitted by Steve Sprengel (not verified) on

Is this an inconsistency that Adobe needs to address in their DNG Converter?

I don't think so.Generally,

Submitted by lexa on

I don't think so.
Generally, BlackLevelRepeatDim 1x1 is useless, because it is equal to simple BlackLevel tag, but nothing in DNG standard forbids this use of BlackLevelRepeatDim tag.

So, the case with 1x1 BlackLevelRepeatDim is not handled properly in RawDigger 1.0.6 and older. Hope, we'll release 1.0.7 today  (it works with 1x1 RepeatDim now, we're discussing what to do with, for example, CFA 6x6 and BlackLevelRepeatDim 1x2. Not real case, but we want to handle it properly too).

And finally, with this DNG

Submitted by lexa on

And finally, with this DNG and RawDigger 1.0.6

1) In Automatic Black Level mode only BL display is incorrect. RGB Rendering and Raw values are OK.

2) Black level suggestions in Preferences and Black Level display on Black Level button are incorrect in automatic mode.

X-Trans DNG - scrambled pixel layout in RawDigger

Submitted by Steve Sprengel (not verified) on

My question, now, is why the Auto Black Level for the DNG (1024) is one different than that of the RAF (1023) even though the values RD reports in the raw data are the same once 0 is manually set as the BL. It seems like Auto BL should work the same between the DNG and the corresponding raw, but perhaps there is something different in the DNG format that is causing the difference. I don't know as I'm not that familiar with the internal workings of DNGs.

And a secondary question: why the final disabled G2 value is now the same as the others rather than 0 like it used to be in the Channels BL. Does that final, disabled second green channel value affect anything? Since I can't enter anything into it I can't experiment to see.
--
Another possibly-related issue, is that another raw file from a totally different brand and model of camera seems to stop partway through the black-level analysis and shows up black in the RGB render and has inconsistent values between the black level button (off) and the computed black level values (800, 800, 800, 800):
https://www.dropbox.com/s/uh92h9otbdqfu2h/2014-03-25_151111.png

Here is the ARW file from a Sony RX100 that exhibits this issue. I haven't reviewed your list of supported cameras, so maybe the RX100 isn't. Evidence for this is that a DNG from this raw file does appear to work properly:
https://www.dropbox.com/s/x8ir4qpyyk2qatp/sony_cybershot_dsc_rx100_01.arw

The black level is 1023 in

Submitted by lexa on

The black level is 1023 in RAF file because BackLevel RAF tag is 1023 (repeated 36 times).
In DNG file BlackLevel is 1024 because of tag set by Adobe converter. I do not know why Adobe DNG Converter changes black level value.

For the second question: you choose Delta Step Relative to value mode of ARW processing. This is very special mode for Sony ARW2 lossy compression analysis. Black level value is ignored (so the mark in preferences is disabled).
If you convert this file to DNG, this very special mode is not available because DNG uses different (not lossy) compression.

The Black Level = 800 is right for RX100 camera.

Forgot to answer another

Submitted by lexa on

Forgot to answer another question.
G2 is disabled for Fuju X-trans because it is 3-channel (3-color) camera with  6x6 CFA pattern. Fuji itself treats it as 3 color (e.g. only 3 coefficients for white balance).

Ok, I just arbitrarily chose

Submitted by Steve Sprengel (not verified) on

Ok, I just arbitrarily chose a different camera model's raw to test with and happened to choose a Sony which has special processing enabled, so it's not an issue.

My question wasn't why the G2 was disabled, my question was why with 1.0.0.6 the disabled value was indicated as 0, and now in 1.0.0.7 the disabled value is indicated by the same as one of the other values and not 0 anymore. I asked why the value was different in case it was a mistake instead of on purpose, since I don't see any reason why it would need to change based on what was fixed with the calculations.

For 3-color files (e.g. Fuji

Submitted by lexa on

For 3-color files (e.g. Fuji X-Trans) the 4th value is not used. So, it does not matter which value is in disabled box.

For BlackLevelDim 1x1 (X100ShVHAB.dng sample) we fill BlackLevel value to all 4 internal RawDigger color channels (because 1x1 may be used not only for 3-color Fuji files, but in 1-color or 4-color ones), so the value in disabled G2 box changes (but not used in BL subtraction).
For 3-color Fuji RAF files, black level calculation remains the same in 1.0.7 , so only 3 BlackLevel values are inited and 4th remains zero.

Also, It looks like that we

Submitted by lexa on

Also, It looks like that we need to display only 3 values on BlackLevel button of main window for 3-color files to not confuse our users.
To be fixed before 1.0.7 official release.

random crash when open a file for 1.07 build 339 (x64)

Submitted by Claude Dumas (not verified) on

Hi,

I get random crash when I open a RAW from D50 or D7000. It occurs after a couple of file opening (sometimes the second one, other time the tenth, etc). it does not seem to depend on specific RAW files. Is there any log file I can send you ?

I. Please specify what OS do

Submitted by lexa on

I. Please specify what OS do you use. Windows? 32 or 64bit? RAM amount on computer?

II. Things to test
1) Turn Off external Exiftool (Preferences - Misc options - clear ExifTool - Path line)

2) Turn off RawSpeed library (Preferences - Data Processing - Use RawSpeed library for decoding).

thanks for the VERY quick

Submitted by Claude Dumas (not verified) on

thanks for the VERY quick response... Here is my system config :
* windows 7 service pack 1
* DirectX V11
* Dell XPS 8300, 12 GB RAM

I've turn off the 2 settings, but the problem persists. Is there any debugging option on the command line I can use ? Any log file ?

thanks

No log file, no debug options

Submitted by lexa on

No log file, no debug options in command line, because these options was not needed before. You're our first user with persistent crashes.

Could you please do downgrade to RawDigger 1.0.4 and test this version (this does not affect any option for D50 or D7000, because 1.0.5-1.0.7 introduces support for Sony ARW and Nikon D4s small NEFs). Here is direct link: http://updates.rawdigger.com/data/RawDigger-1.0.4.305-x64-Setup.exe

Also, could you please upload some of your test files with problems to somewere (Dropbox or so and send link to files) for our internal testing. You may use support@rawdigger.com if you do not wish to make these files public.

Add new comment