I just purchased RawDigger and FastRawViewer. Great programs both! I haven't noticed any bugs, but do have a few suggestions for improvement of RawDigger:
1) Have O and U toggle Overexposure and Underexposure like they do in FastRawViewer
2) Have the option to have the Histogram next to the image in (which would be moved to the left) in the same window so I don't have to keep opening and closing the histogram or switching to a different window
1) O/U shortcuts for exposure warning is a good idea, added to TODO list.
2) Small histogram is a different story:
- RawDigger histograms are precise: no approximation, each bin occupies an integer number of pixels
- There are a lot of controls in Histogram window (type, scale settings, etc)
- It is possible to use many histograms at once (full image, selection, several samples)
So, there is no way to show precise histogram with controls in main program window on the small display.
We suggest you to run RawDigger from FRV. FRV already shows approximate small histogram, if you need details examination you may run RawDigger by single keypress ('R' if RawDigger was found on FRV installation, if not you may need to visit FRV Preferences-External Programs and add RawDigger to external program list)
"So, there is no way to show precise histogram with controls in main program window on the small display.
We suggest you to run RawDigger from FRV. FRV already shows approximate small histogram, if you need details examination you may run RawDigger by single keypress ('R' if RawDigger was found on FRV installation, if not you may need to visit FRV Preferences-External Programs and add RawDigger to external program list)"
OK, understood. I did open RawDigger from FRV. How about an option in FRV to open image in RawDigger with histogram of full image automatically opened? That is what I want. I had to Control-H every time I opened image in RawDigger from FRV. Not the worst problem, but would be easier (for me) with that option. Or the option could be in RawDigger that every time an image is opened it would open with histogram of full image.
In RawDigger: Menu-File-Preferences-Misc options, set 'Run Single program instance', then close RawDigger to take this setting into effect.
After that:
1) Press R in FRV to run RawDigger on 1-st file. Open Histogram window
Do not close RawDigger
2) Press 'R' in FRV on the second file. The file to be passed to current running RawDigger with histogram window open. You may need to switch back to RawDigger (with new file) by alt-tab.
Unfortunately, there is no easy way to start RD with histogram window open because of
- RawDigger can be started without (startup) Raw file
- And it cannot show histogram window without data passed to it (by internal design)
No matter how I set the overexposure limits in RawDigger, the number of pixels overexposed is way different than with FRV. Example: on one image in RawDigger, I get 141K to 156K (for green channel) with different auto/manual settings. However, in FRV it lists 312K overexposure for the same channel. Oddly enough, FRV lists 3% overexposure, while RawDigger lists 3.1% overexposure (for manual setting that gives 141K overexposure). These numbers seem contradictory. Is this expected?
In FastRawViewer, the statistics in green is over a composite green raw channel, G1+G2; while in RawDigger it is separate for each channel, G1 and G2. So, the statistics is in agreement.
FRV uses histogram with ~1/20EV step, then calculates overexposure limit from this histogram. So, Overexposure level is also with 1/20EV step precision (enouth for any practical purpose because this is beyond light metering accuracy
RawDigger uses precise histogram with 1 level accuracy. So, even with same OE detection method (FullWell capacity in RD), exact OE level may differ up to ~1/20EV, so statistics will differ slightly (3.0 vs 3.1%).
"FRV uses histogram with ~1/20EV step, then calculates overexposure limit from this histogram. So, Overexposure level is also with 1/20EV step precision (enouth for any practical purpose because this is beyond light metering accuracy
RawDigger uses precise histogram with 1 level accuracy. So, even with same OE detection method (FullWell capacity in RD), exact OE level may differ up to ~1/20EV, so statistics will differ slightly (3.0 vs 3.1%)."
Excellent explanation, would be a good idea to include this in the manual(s).
I have one other feature request. In FRV you can turn off "Apply Hidden Adobe Exposure Correction". However, you can't do this in RawDigger. I would like to see that feature added. I like to have the displayed images match visually. Currently, you have to have "Apply Hidden Adobe Exposure Correction" checked in FRV to get a visual match.
RawDigger's RGB rendering is for reference only (bayer RGB composite is too green for default display and may confuse novice users).
Standard settings for FRV and RD display are very different because of different purpose:
RD defaults are set to show acceptable reference image even if image is underexposed heavily. So, in default settings, 'Automatic exposure correction' is set to on.
FRV is set up to match Adobe tools output (because Adobe tools are most used for RAW conversion), so 'hidden' exposure correction is applied (but no other automatic corrections), contrast curve is set to 'Adobe Linear'.
So, there are two ways to match FRV and RD rgb rendering closely (but not exactly)
a) turn off 'Adobe correction' in FRV and turn off 'Automatic exposure correction for RGB render' in RD Prefs -> Display options
or
b) set FRV's Prefs - Image Display - Exposure correction on file open to Autoexposure (or press Shift-A on file open), set contrast curve to gamma 2.2, and keep RD's autoexposure on.
I bought RD Profile Edition a few days ago, and I noticed a few things (running on MAC OS 10.11.1) :
1. The minus '-' button to adjust image size appears in a BIG box : much bigger than the plus button. It works, though.
2. Since one of the 'Profile Edition''s goal is to, well, help people get measurements for profiling, I think the "Selection Grid" menu/window could/should be more convenient. Perhaps its due to my OS (?), but the Selection Grid window gets hidden by the main window each time I use it (the main window) so, would it be possible to :
- add a shortcut to call the 'Selection Grid' tool, or make the window reappear ?
- or perhaps add an option to force this window on foreground ?
- add a 'Grid window' option in the 'Window' menu, so that it would always be possible to switch from one window to that one in particular ?
Grid setup dialog can be turned on/off via Cmd-G shortcut (if the window is hidden under other windows, just press Cmd-G twice)
In Preferences - Misc Options you can check 'Put grid setup dialog on top of all Windows' checkbox. It will take effect after program restart, not immediately, the Grid Setup window to be on top of all windows (of all applications).
Zoom out button on bottom bar is now correct size on OS X 10.11
Thank you for your replies. I have just tested this version and everything works just like you wrote : excellent work. I will now replace the previous version with that one.
Now, I can just complain about the grid animation, which is quite slow and a bit jerky (I currently work on a 570 patches target) : it takes some time to adjust the grid.
Please try decrreasing the minimum cell size ( http://www.rawdigger.com/usermanual/selection-grid ) - I have it at 3 for large non-alighed targets or grey step wedges; also it helps to use Ctrl when changing the size of the whole grid (Moving corners -> While Ctrl is pressed simultaneously with the left mouse button you can change the dimensions of the grid). In a lot of cases I start with the fill factor of about 50% (ROI relative size), having Show cell ID/Name off.
(I always read the manual before using a software ;-) hence I was used to the Ctrl-thing : Cmd for me, as a Mac user). I use a ROI relative size of 0,5 as well ! But I used to let Show Cell ID/Name ON. I tried to unselect it and I got a perfectly fluid experience with the grid animation (the difference is huge : perhaps related to some graphic feature poorly handled by Mac OSX).
By the way, I noticed some serious bug by playing with the Show Cell ID/Name option :
- setting it OFF is quite quick
- but setting it ON again, with the grid displayed (without touching anything) is insanely slow and demanding on the CPU : I got one core fully loaded and busy for about three minutes just to show the Cell IDs back ! I mean : during that time, RawDigger does not respond in any way, and the multicolor wheel is spinning all the time... Just crazy.
(I'm using a MacBook Pro Retina Late 2013, so the machine itself is not so sluggish for general computing)
Best regards, a a big thank you for your very quick answers,
Fabien Audry
Thank you for the update. It's a little odd the speed with Show Cell ID/Name being on is such a factor. Maybe it is something specific to 10.11 - will check.
1) Placing cell names is fast on orthogonal grid, but not so fast if the grid is skewed
2) On skewed grid it is 'fast enough' on windows (that's why we've not noticed it yet), but terrible slow under OS X 10.11 (have not tested under previous OS X versions yet).
We'll contact you when we'll have something to test.
In Sigma dp Quattro files, a significant number of pixels in dark image areas are reported by RawDigger 1.2.6 and 1.2.7 as overexposed. This happens only in red and green channels. Overexposed pixels are not generally the same in both channels, and usually change between frames made within a fraction of a second. An example can be seen in the Appendix of this article: http://philservice.typepad.com/Sigma_Merrill_vs_Quattro/1_Signal_Noise_S...
As a temporary solution, go to Preferences - Data Processing - Vendor specific and turn off 'Low sensitivity pixel interpolation' in Sigma dpN Quattro section.
It looks like these pixels are averaged incorrectly in low-signal area.
That was fast! Thanks very much. I wonder also if there is some way to trim excess pixels off the images as opened by RawDigger. RawDigger shows raw image size as 5888 x 3672. Actual size is 5424 x 3616. Only inconvenient in that it exaggerates the amount of underexposure. Perhaps I'm missing a preference setting?
Follow-up to my previous message. Using RawDigger 1.2.9, it looks like the actual number of exposed pixels is 5448 x 3624. Apparently Sigma PhotoPro trims that to 5414 x 3616. Still, that's a lot less than the 5888 x 3672 reported by RawDigger. This image might help:
The full sensor area (with optical black pixels) for this sensor is 5888x3672 (with Masked pixels display on). This is real size of sensor pixel array.
The image area is 5446x3624. As you can see, this is real image area with real image pixels.
RawDigger always try to show maximum possible visible area. If you need to limit your image inspection (histogram, etc) to Sigma ProPhoto area, you may use Menu - Selection - Set Selection by number.
We do not know why software authors set visible area less than real one.
Thank you very much for your responses. Yes, I thought about the Set Selection by number option. In fact that's how I discovered that the actual image pixel area was greater than the image size in Photo Pro. Thank you also for RawDigger. I find it very useful.
I just ran into an odd situation. I made some panoramas in Adobe Lightroom, the result is a DNG file. Panorama looks fine in Lightroom.
Individual images used to make the panorama look fine in RawDigger, but the DNG file produced by the panorama creation shows as grossly over exposed in RawDigger. This looks like a bug or limitation in RawDigger, but wanted to check here first. Raw files are from Canon t2i. I have RawDigger 1.2.11 running on Win 7/64.
Could you please upload a sample of such a panorama DNG? It looks like there is some inconsistency in metadata in your samples, and it is better to study a sample than to guess.
Thank you. The green channel on the panorama is blown out for the clouds, much of the blue channel too, as it is denoted in OE statistics in RawDigger. Lr/ACR apply highlight recovery; RawDigger displays raw as it is. You may prefer RawDigger preview in "Raw composite" mode ("Display" section) for such cases, to avoid application of white balance.
Thanks. Would you expect this to affect ultimate image quality? Recovery implies that some of the information was thrown away and LR is trying to guess at the colors. Would you consider this a bug in LR panorama creation or a "feature"?
I can't say if it is a bug - please check the source raw files, do they have a similar problem?
If Lr somehow clipped the channels, going from source files to pano, I would say it is a bug. Otherwise it is a workaround for clipped highlights, that's all IMHO.
Problem solved... turned out to be user error. Settings were wrong for overexposure warning (haven't used RawDigger for a while). Interestingly though, LR does not show the blown channels in the original images properly. I guess it applied highlight recovery in the background before displaying the original image. RawDigger unmasks the truth!
It seems that RawDigger is a bit "lost" with photos that are shot in Automatic Exposure Bracketing. More precisely, the exposure compensation that is shown in the main window ignores the AEB offset, which is confusing imho. As an example, for a Canon RC2 file, RawDigger should add the "AEB Bracket Value" to "Exposure Compensation" and displays this sum. FYI, that's the behavior of Lightroom and FastRawViewer.
Oh one more thing. How RawDigger is "computing" the 35 mm focal equivalence ? Because with a 35mm fixed-focal lens on a Canon 1Dx, RawDigger displays "@35.0 mm (35 mm equivalent: 33.9 XXX)" with XXX is, I guess (alas it is hidden by the EXIF button) : "mm)"
Is it the real focal of the lens taking into account the subject distance (I know some lens are subject to focus breathing) ? Or is it a calculus error ? Whatever, the sentence "35 mm equivalent" is both too long (because of the Exif button hiding the remaining of the text) and confusing (with "full frame" camera).
FYI, FRV doesn't show a specific "FL-35mm" for this photo (of course I have checked this option in the Exif preferences options).
It's probably something stupid that I'm doing now, but when I make a selection, convert it to samples, and open the samples window, I can see mean, sigma, min and max for all four channels. But when I save the sample as a csv file, all I see is the four mean values. Last time I tried this, it worked fine, but I've upgraded RD versions since then. When I copy the data to the clipboard, I get it all.
What should I do to get all the stats saved to the csv file? I've looked through the preferences without success.
I suspect I'm gonna go "doh" when I hear back from you guys.
Inconsistent minimisation of Hist, EXIF, Sample windows (Win10)
Hello.
This is on up-to-date MS Windows 10.
- If I have some combination of Histogram, EXIF, Sample windows open, then if the main RawDigger window is minimised, some, all, or none of the other windows may be minimised.
For example I currently have RawDigger open on two machines, with Histogram, EXIF, and Sample windows open.
- On machine 1, If I minimise the main RawDigger window, the histogram is minimised, but the other two windows remain on the screen. (Histogram window isn't shown when I mouse-over the toolbar RawDigger icon).
- On Machine 2, If I minimise RawDigger, all 3 other windows remain on-screen.
I don't think this is a machine difference. The exact behaviour doesn't seem consistent over time.
I'm somewhat expecting an answer that points me to some strange RawDigger setting I've made :-)
Related to this, it isn't possible to minimise or maximise the secondary windows. It would be useful to be able to do that at least with the histogram window, when running RawDigger on a small screen. But that's a feature request, so I'll make a separate entry for that.
This is on up-to-date Win10, with RawDigger 1.2.26 build 599 (x64).
If I start RawDigger with Data Processing->Linear Raw Curve checked, The stats and histogram display non-expanded data (more or less as expected, see other bug report regarding Linear Raw Curve with Nikon D5300).
If I then uncheck Processing->Linear Raw Curve, stats and histogram update to show normal range data, as expected.
If I then check Data Processing->Linear Raw Curve (and click apply or OK), nothing happens to stats or histogram. Using the "Linear Raw Curve" feature requires restarting RawDigger.
If you happen to have any raw files from cameras that are not yet supported, including new and pre-production models, please, contact us for the support.
Fast Raw Viewer is the first and the only dedicated tool specifically designed and developed for extremely fast display, visual and technical analysis, basic corrections, sorting and setting aside or directly transferring for further processing of RAW images.
Suggestions for RawDigger
Submitted by John Hollenberg (not verified) on
I just purchased RawDigger and FastRawViewer. Great programs both! I haven't noticed any bugs, but do have a few suggestions for improvement of RawDigger:
1) Have O and U toggle Overexposure and Underexposure like they do in FastRawViewer
2) Have the option to have the Histogram next to the image in (which would be moved to the left) in the same window so I don't have to keep opening and closing the histogram or switching to a different window
1) O/U shortcuts for exposure
Submitted by lexa on
1) O/U shortcuts for exposure warning is a good idea, added to TODO list.
2) Small histogram is a different story:
- RawDigger histograms are precise: no approximation, each bin occupies an integer number of pixels
- There are a lot of controls in Histogram window (type, scale settings, etc)
- It is possible to use many histograms at once (full image, selection, several samples)
So, there is no way to show precise histogram with controls in main program window on the small display.
We suggest you to run RawDigger from FRV. FRV already shows approximate small histogram, if you need details examination you may run RawDigger by single keypress ('R' if RawDigger was found on FRV installation, if not you may need to visit FRV Preferences-External Programs and add RawDigger to external program list)
"So, there is no way to show
Submitted by John Hollenberg (not verified) on
"So, there is no way to show precise histogram with controls in main program window on the small display.
We suggest you to run RawDigger from FRV. FRV already shows approximate small histogram, if you need details examination you may run RawDigger by single keypress ('R' if RawDigger was found on FRV installation, if not you may need to visit FRV Preferences-External Programs and add RawDigger to external program list)"
OK, understood. I did open RawDigger from FRV. How about an option in FRV to open image in RawDigger with histogram of full image automatically opened? That is what I want. I had to Control-H every time I opened image in RawDigger from FRV. Not the worst problem, but would be easier (for me) with that option. Or the option could be in RawDigger that every time an image is opened it would open with histogram of full image.
This trick will help:
Submitted by lexa on
This trick will help:
In RawDigger: Menu-File-Preferences-Misc options, set 'Run Single program instance', then close RawDigger to take this setting into effect.
After that:
1) Press R in FRV to run RawDigger on 1-st file. Open Histogram window
Do not close RawDigger
2) Press 'R' in FRV on the second file. The file to be passed to current running RawDigger with histogram window open. You may need to switch back to RawDigger (with new file) by alt-tab.
Unfortunately, there is no easy way to start RD with histogram window open because of
- RawDigger can be started without (startup) Raw file
- And it cannot show histogram window without data passed to it (by internal design)
I noticed one issue (may not
Submitted by John Hollenberg on
I noticed one issue (may not be a bug, though):
No matter how I set the overexposure limits in RawDigger, the number of pixels overexposed is way different than with FRV. Example: on one image in RawDigger, I get 141K to 156K (for green channel) with different auto/manual settings. However, in FRV it lists 312K overexposure for the same channel. Oddly enough, FRV lists 3% overexposure, while RawDigger lists 3.1% overexposure (for manual setting that gives 141K overexposure). These numbers seem contradictory. Is this expected?
Dear Sir,
Submitted by Iliah Borg on
Dear Sir,
Can you please make the raw file available? You can e-mal the link to support@fastrawviewer.com if you wish to keep it private.
--
Best regards,
Iliah Borg
Dear Sir:
Submitted by Iliah Borg on
Dear Sir:
The file is received OK, thank you very much.
In FastRawViewer, the statistics in green is over a composite green raw channel, G1+G2; while in RawDigger it is separate for each channel, G1 and G2. So, the statistics is in agreement.
--
Best regards,
Iliah Borg
This is not 'expected', but
Submitted by lexa on
This is not 'expected', but possible:
FRV uses histogram with ~1/20EV step, then calculates overexposure limit from this histogram. So, Overexposure level is also with 1/20EV step precision (enouth for any practical purpose because this is beyond light metering accuracy
RawDigger uses precise histogram with 1 level accuracy. So, even with same OE detection method (FullWell capacity in RD), exact OE level may differ up to ~1/20EV, so statistics will differ slightly (3.0 vs 3.1%).
"FRV uses histogram with ~1
Submitted by John Hollenberg on
"FRV uses histogram with ~1/20EV step, then calculates overexposure limit from this histogram. So, Overexposure level is also with 1/20EV step precision (enouth for any practical purpose because this is beyond light metering accuracy
RawDigger uses precise histogram with 1 level accuracy. So, even with same OE detection method (FullWell capacity in RD), exact OE level may differ up to ~1/20EV, so statistics will differ slightly (3.0 vs 3.1%)."
Excellent explanation, would be a good idea to include this in the manual(s).
I have one other feature request. In FRV you can turn off "Apply Hidden Adobe Exposure Correction". However, you can't do this in RawDigger. I would like to see that feature added. I like to have the displayed images match visually. Currently, you have to have "Apply Hidden Adobe Exposure Correction" checked in FRV to get a visual match.
RawDigger's RGB rendering is
Submitted by lexa on
RawDigger's RGB rendering is for reference only (bayer RGB composite is too green for default display and may confuse novice users).
Standard settings for FRV and RD display are very different because of different purpose:
So, there are two ways to match FRV and RD rgb rendering closely (but not exactly)
a) turn off 'Adobe correction' in FRV and turn off 'Automatic exposure correction for RGB render' in RD Prefs -> Display options
or
b) set FRV's Prefs - Image Display - Exposure correction on file open to Autoexposure (or press Shift-A on file open), set contrast curve to gamma 2.2, and keep RD's autoexposure on.
Hello,
Submitted by Fabien AUDRY (not verified) on
Hello,
I bought RD Profile Edition a few days ago, and I noticed a few things (running on MAC OS 10.11.1) :
1. The minus '-' button to adjust image size appears in a BIG box : much bigger than the plus button. It works, though.
2. Since one of the 'Profile Edition''s goal is to, well, help people get measurements for profiling, I think the "Selection Grid" menu/window could/should be more convenient. Perhaps its due to my OS (?), but the Selection Grid window gets hidden by the main window each time I use it (the main window) so, would it be possible to :
- add a shortcut to call the 'Selection Grid' tool, or make the window reappear ?
- or perhaps add an option to force this window on foreground ?
- add a 'Grid window' option in the 'Window' menu, so that it would always be possible to switch from one window to that one in particular ?
Anyway, thanks for your good work,
Fabien
Thank you for your problem
Submitted by lexa on
Thank you for your problem reports, it looks like OS X 10.11 requires additional interface tune.
To be fixed/improved in next minor update.
Dear Fabien,
Submitted by lexa on
Dear Fabien,
could you please test RawDigger 1.2.2 (not published on site yet, direct link to OS X download is: http://updates.rawdigger.com/data/RawDigger-1.2.2.433.dmg )
In this version:
Hello,
Submitted by Fabien (not verified) on
Hello,
Thank you for your replies. I have just tested this version and everything works just like you wrote : excellent work. I will now replace the previous version with that one.
Now, I can just complain about the grid animation, which is quite slow and a bit jerky (I currently work on a 570 patches target) : it takes some time to adjust the grid.
Thank you very much, and keep on the good work !
Please try decrreasing the
Submitted by Iliah Borg on
Please try decrreasing the minimum cell size ( http://www.rawdigger.com/usermanual/selection-grid ) - I have it at 3 for large non-alighed targets or grey step wedges; also it helps to use Ctrl when changing the size of the whole grid (Moving corners -> While Ctrl is pressed simultaneously with the left mouse button you can change the dimensions of the grid). In a lot of cases I start with the fill factor of about 50% (ROI relative size), having Show cell ID/Name off.
--
Best regards,
Iliah Borg
Hello,
Submitted by Fabien (not verified) on
Hello,
(I always read the manual before using a software ;-) hence I was used to the Ctrl-thing : Cmd for me, as a Mac user). I use a ROI relative size of 0,5 as well ! But I used to let Show Cell ID/Name ON. I tried to unselect it and I got a perfectly fluid experience with the grid animation (the difference is huge : perhaps related to some graphic feature poorly handled by Mac OSX).
By the way, I noticed some serious bug by playing with the Show Cell ID/Name option :
- setting it OFF is quite quick
- but setting it ON again, with the grid displayed (without touching anything) is insanely slow and demanding on the CPU : I got one core fully loaded and busy for about three minutes just to show the Cell IDs back ! I mean : during that time, RawDigger does not respond in any way, and the multicolor wheel is spinning all the time... Just crazy.
(I'm using a MacBook Pro Retina Late 2013, so the machine itself is not so sluggish for general computing)
Best regards, a a big thank you for your very quick answers,
Fabien Audry
Thanks again for the report!
Submitted by lexa on
Thanks again for the report!
Dear Sir:
Submitted by Iliah Borg on
Dear Sir:
Thank you for the update. It's a little odd the speed with Show Cell ID/Name being on is such a factor. Maybe it is something specific to 10.11 - will check.
--
Best regards,
Iliah Borg
Problem confirmed:
Submitted by lexa on
Problem confirmed:
1) Placing cell names is fast on orthogonal grid, but not so fast if the grid is skewed
2) On skewed grid it is 'fast enough' on windows (that's why we've not noticed it yet), but terrible slow under OS X 10.11 (have not tested under previous OS X versions yet).
We'll contact you when we'll have something to test.
Hi,
Submitted by Fabien AUDRY on
Hi,
I just tested this new version (1.2.3), and it works fine. Moving the grid and displaying the Cell ID is now fully useable.
Thank you.
Best regards,
Fabien
Thank you for letting us know
Submitted by lexa on
Thank you for letting us know that the problem solved.
Feel free to contact us with any questions, suggestions or bug reports.
Bug report: Incorrect overexposure warning in Sigma Quattro
Submitted by Phil Service (not verified) on
In Sigma dp Quattro files, a significant number of pixels in dark image areas are reported by RawDigger 1.2.6 and 1.2.7 as overexposed. This happens only in red and green channels. Overexposed pixels are not generally the same in both channels, and usually change between frames made within a fraction of a second. An example can be seen in the Appendix of this article: http://philservice.typepad.com/Sigma_Merrill_vs_Quattro/1_Signal_Noise_S...
Could you please provide some
Submitted by lexa on
Could you please provide some RAW files for inspection?
Pixels incorrectly reported as overexposed in dp Quattro
Submitted by Phil Service (not verified) on
These two images should suffice. Taken within a few seconds of each other. Check red and green channels in dark parts of the 4x5 step wedge
https://www.dropbox.com/s/wn8xig4et617u1a/DP1Q0485.X3F?dl=0
https://www.dropbox.com/s/sysa11h4phs2lwa/DP1Q0486.X3F?dl=0
As a temporary solution, go to Preferences - Data Processing
Submitted by lexa on
As a temporary solution, go to Preferences - Data Processing - Vendor specific and turn off 'Low sensitivity pixel interpolation' in Sigma dpN Quattro section.
It looks like these pixels are averaged incorrectly in low-signal area.
Thank you for the problem report.
Followup: the problem has
Submitted by lexa on
Followup: the problem has fixed in RawDigger 1.2.9: http://www.rawdigger.com/download
please upgrade.
Sigma DP Quattro - thanks and ...
Submitted by Phil Service (not verified) on
That was fast! Thanks very much. I wonder also if there is some way to trim excess pixels off the images as opened by RawDigger. RawDigger shows raw image size as 5888 x 3672. Actual size is 5424 x 3616. Only inconvenient in that it exaggerates the amount of underexposure. Perhaps I'm missing a preference setting?
dpN Quattro Image area
Submitted by Phil Service (not verified) on
Follow-up to my previous message. Using RawDigger 1.2.9, it looks like the actual number of exposed pixels is 5448 x 3624. Apparently Sigma PhotoPro trims that to 5414 x 3616. Still, that's a lot less than the 5888 x 3672 reported by RawDigger. This image might help:
https://www.dropbox.com/s/jhqrwn5jphknd4k/SDIM0400.X3F?dl=0
The full sensor area (with
Submitted by lexa on
The full sensor area (with optical black pixels) for this sensor is 5888x3672 (with Masked pixels display on). This is real size of sensor pixel array.
The image area is 5446x3624. As you can see, this is real image area with real image pixels.
RawDigger always try to show maximum possible visible area. If you need to limit your image inspection (histogram, etc) to Sigma ProPhoto area, you may use Menu - Selection - Set Selection by number.
We do not know why software authors set visible area less than real one.
dpN Quattro
Submitted by Phil Service (not verified) on
Thank you very much for your responses. Yes, I thought about the Set Selection by number option. In fact that's how I discovered that the actual image pixel area was greater than the image size in Photo Pro. Thank you also for RawDigger. I find it very useful.
RawDigger Error with DNG Produced by Lightroom Panorama?
Submitted by John S Hollenberg (not verified) on
I just ran into an odd situation. I made some panoramas in Adobe Lightroom, the result is a DNG file. Panorama looks fine in Lightroom.
Individual images used to make the panorama look fine in RawDigger, but the DNG file produced by the panorama creation shows as grossly over exposed in RawDigger. This looks like a bug or limitation in RawDigger, but wanted to check here first. Raw files are from Canon t2i. I have RawDigger 1.2.11 running on Win 7/64.
Thoughts?
Dear Sir:
Submitted by Iliah Borg on
Dear Sir:
Could you please upload a sample of such a panorama DNG? It looks like there is some inconsistency in metadata in your samples, and it is better to study a sample than to guess.
--
Best regards,
Iliah Borg
OK, here is a 2 image
Submitted by John S Hollenberg (not verified) on
OK, here is a 2 image panorama I made as a test case. Shows the same problem:
https://dl.dropboxusercontent.com/u/48149991/_MG_7084-Pano.dng
Dear Sir:
Submitted by Iliah Borg on
Dear Sir:
Thank you. The green channel on the panorama is blown out for the clouds, much of the blue channel too, as it is denoted in OE statistics in RawDigger. Lr/ACR apply highlight recovery; RawDigger displays raw as it is. You may prefer RawDigger preview in "Raw composite" mode ("Display" section) for such cases, to avoid application of white balance.
--
Best regards,
Iliah Borg
Thanks. Would you expect
Submitted by John S Hollenberg (not verified) on
Thanks. Would you expect this to affect ultimate image quality? Recovery implies that some of the information was thrown away and LR is trying to guess at the colors. Would you consider this a bug in LR panorama creation or a "feature"?
Dear Sir:
Submitted by Iliah Borg on
Dear Sir:
I can't say if it is a bug - please check the source raw files, do they have a similar problem?
If Lr somehow clipped the channels, going from source files to pano, I would say it is a bug. Otherwise it is a workaround for clipped highlights, that's all IMHO.
--
Best regards,
Iliah Borg
Problem solved... turned out
Submitted by John S Hollenberg (not verified) on
Problem solved... turned out to be user error. Settings were wrong for overexposure warning (haven't used RawDigger for a while). Interestingly though, LR does not show the blown channels in the original images properly. I guess it applied highlight recovery in the background before displaying the original image. RawDigger unmasks the truth!
Some data could be more precise
Submitted by Larate (not verified) on
Hello,
It seems that RawDigger is a bit "lost" with photos that are shot in Automatic Exposure Bracketing. More precisely, the exposure compensation that is shown in the main window ignores the AEB offset, which is confusing imho. As an example, for a Canon RC2 file, RawDigger should add the "AEB Bracket Value" to "Exposure Compensation" and displays this sum. FYI, that's the behavior of Lightroom and FastRawViewer.
Oh one more thing. How RawDigger is "computing" the 35 mm focal equivalence ? Because with a 35mm fixed-focal lens on a Canon 1Dx, RawDigger displays "@35.0 mm (35 mm equivalent: 33.9 XXX)" with XXX is, I guess (alas it is hidden by the EXIF button) : "mm)"
Is it the real focal of the lens taking into account the subject distance (I know some lens are subject to focus breathing) ? Or is it a calculus error ? Whatever, the sentence "35 mm equivalent" is both too long (because of the Exif button hiding the remaining of the text) and confusing (with "full frame" camera).
FYI, FRV doesn't show a specific "FL-35mm" for this photo (of course I have checked this option in the Exif preferences options).
Looking for reading your answer,
Regards
Larate
1.2.15 Incomplete sample stats in csv files
Submitted by Jim Kasson (not verified) on
It's probably something stupid that I'm doing now, but when I make a selection, convert it to samples, and open the samples window, I can see mean, sigma, min and max for all four channels. But when I save the sample as a csv file, all I see is the four mean values. Last time I tried this, it worked fine, but I've upgraded RD versions since then. When I copy the data to the clipboard, I get it all.
What should I do to get all the stats saved to the csv file? I've looked through the preferences without success.
I suspect I'm gonna go "doh" when I hear back from you guys.
Jim
Hi Jim,
Submitted by Iliah Borg on
Hi Jim,
When you are saving samples via "Save Samples to File", do you have "StdDev Values" checked? When I do, my csv header looks this way:
"Id","Sample_Name","Rmin","Ravg","Rmax","Rdev","Gmin","Gavg","Gmax","Gdev","Bmin","Bavg","Bmax","Bdev","G2min","G2avg","G2max","G2dev"--
Best regards,
Iliah Borg
Same samples to file
Submitted by Jim Kasson (not verified) on
Ah, I see now. Has that always been there? Has it always been unchecked by default?
I knew I'd end up feeling stupid about this.
Thanks,
Jim
Yes, it is always here (since
Submitted by lexa on
Yes, it is always here (since RawDigger 1.0 or 0.9 betas).
These dialog settings are remembered from run to run, so next time this checkbox will be checked.
Thanks for the help! <NT>
Submitted by Jim Kasson (not verified) on
Required field.
Jim,
Submitted by Iliah Borg on
Jim,
You are always very welcome. Reading your slit scan series, most interesting, thank you.
--
Best regards,
Iliah Borg
Inconsistent minimisation of Hist, EXIF, Sample windows (Win10)
Submitted by John Vickers on
Inconsistent minimisation of Hist, EXIF, Sample windows (Win10)
Hello.
This is on up-to-date MS Windows 10.
- If I have some combination of Histogram, EXIF, Sample windows open, then if the main RawDigger window is minimised, some, all, or none of the other windows may be minimised.
For example I currently have RawDigger open on two machines, with Histogram, EXIF, and Sample windows open.
- On machine 1, If I minimise the main RawDigger window, the histogram is minimised, but the other two windows remain on the screen. (Histogram window isn't shown when I mouse-over the toolbar RawDigger icon).
- On Machine 2, If I minimise RawDigger, all 3 other windows remain on-screen.
I don't think this is a machine difference. The exact behaviour doesn't seem consistent over time.
I'm somewhat expecting an answer that points me to some strange RawDigger setting I've made :-)
Related to this, it isn't possible to minimise or maximise the secondary windows. It would be useful to be able to do that at least with the histogram window, when running RawDigger on a small screen. But that's a feature request, so I'll make a separate entry for that.
Regards,
Dear Sir:
Submitted by lexa on
Dear Sir:
are implemented in RawDigger 1.3 beta: https://www.rawdigger.com/news/rawdigger-1-3-beta
Inconsistency in Linear Curve Mode which requires file reload is also fixed.
Toggling Data Processing->Linear Raw Curve
Submitted by John Vickers on
Toggling Data Processing->Linear Raw Curve
Hello again.
A minor thing.
This is on up-to-date Win10, with RawDigger 1.2.26 build 599 (x64).
If I start RawDigger with Data Processing->Linear Raw Curve checked, The stats and histogram display non-expanded data (more or less as expected, see other bug report regarding Linear Raw Curve with Nikon D5300).
If I then uncheck Processing->Linear Raw Curve, stats and histogram update to show normal range data, as expected.
If I then check Data Processing->Linear Raw Curve (and click apply or OK), nothing happens to stats or histogram. Using the "Linear Raw Curve" feature requires restarting RawDigger.
Regards,
Reloading of current file
Submitted by lexa on
Reloading of current file (Menu - File - Recent files - topmost one) should be enough.
OK, Thanks.
Submitted by John Vickers on
OK, Thanks.
We'll address this in next
Submitted by lexa on
We'll address this in next intermediate update (1.3.0): Linear Curve button should not be disabled if linear curve is selected
Pages
Add new comment