Recent comments

Reply to: Nikon NEF RAW data minimum value clamp   1 week 5 hours ago

Iliah,
I did notice that Nikon hacker claims to have a hack for the D5100 and D7000. I also e-mailed Nikon to ask if an "astronomy firmware" update could be made available for the D5300. Nikon has not responded yet, which is a shame because Nikon Hacker gives me the impression that it is possible to do.

Thanks once again for clarifying...it's nice to know that someone is continuing to support the efforts begun by Dave Coffin.

Peter

Reply to: Nikon NEF RAW data minimum value clamp   1 week 6 hours ago

Dear Sir:

Sorry for being unclear. Yes, the raw data in the NEF file is clamped at 588. There are no values below, and no way of recovering the missing values from the data - they are not there. As far as I know hacks to obtain true dark current and to disable star eater are available for D5100 and D7000, but you can reach out to nikon hacker community for more up-to-date info on the subject.

Reply to: Nikon NEF RAW data minimum value clamp   1 week 7 hours ago

Iliah,
Are you saying that the RAW data in the file is clamped at 588 and that there is no possibility of recovering the unclamped values?

Peter

Reply to: Nikon NEF RAW data minimum value clamp   1 week 7 hours ago

Dear Sir:
I checked the file, black is indeed at 588, clamping is evident.

Reply to: Nikon NEF RAW data minimum value clamp   1 week 7 hours ago

Yes...I understand the precautions for taking DARKs. I also add a computer fan blowing air on the rear of the camera to limit the heat buildup in the camera.

Reply to: Nikon NEF RAW data minimum value clamp   1 week 7 hours ago

Dear Sir:

Could you please upload the dark frame from your Nikon for analysis and send us the link to info@libraw.org ?

On a side note, it is not always sufficient to cover the lens, for dSLRs I cover the viewfinder too. Covering the whole camera may result in increased heat buildup. I also remove batteries and use an external power source.

Reply to: Nikon NEF RAW data minimum value clamp   1 week 8 hours ago

I agree that the black level for a Nikon NEF file is 600. For a 14b Canon CR2 file this black level is 2048. When I look at a Canon ISO 1600 300 second exposure DARK frame (lens cap installed blacking all light) I notice that there are pixel values much lower than 2048. If you view the Canon data as a histogram you see a full bell curve shaped histogram centered at roughly 2048. The values extend downwards to 1800 or more.

For a similar Nikon NEF DARK frame the histogram is centered at 600 but the entire left hand side of the histogram is "missing". These values have all been clamped at a 588 minimum. I need access to the full histogram of values so that I can average multiple DARK frames to reduce the random noise and isolate the DARK current signal. I can do this quite effectively with a Canon camera. Doing this with a Nikon camera is less effective simply because of the huge number of values clamped at the 588 minimum.

Reply to: Nikon NEF RAW data minimum value clamp   1 week 9 hours ago

Nikon D5300 black level value seems to be 600

Reply to: use_camera_wb   1 week 5 days ago

Yes, it is better to use same compiler flags for both app and library :)

Also, your C-API getter/setter patches are welcome

Reply to: use_camera_wb   1 week 5 days ago

Thanks - this turned out to be a problem of my own making. I'll pass it along in case anyone runs into the same issue.

I'm developing under Windows.

I built the libraw.dll library using the VC++ project included with the distribution.

The software that calls libraw.dll is developed using a different compiler. There appear to be some object size and alignment differences between them. As such, things in libraw_data_t weren't where the calling program expected them to be. Setting use_camera_wb from the calling program actually wrote the int to the wrong place.

I worked around this by writing some additional get and set functions so the data in a libraw_data_t need never be accessed directly by the calling program.

Thanks again for your help, and for a great library.

::Jack

Reply to: use_camera_wb   1 week 5 days ago

use_camera_wb=1 will force to use RAW-embedded color profile for Sony cameras (because use_camera_matrix is set to 1 by default, that means use it with camera-provided WB, but do not use if other WB is set). This may be problem cause if, for example, RAW-embedded profile is bad or damaged.

Could you please provide this specific raw sample for analysis? You may E-mail it to info@libraw.org (our mail server accepts up to 70Mb attachments, so most sony files, except 14-bit uncompressed 40Mpix will pass). Or upload it somewhere (Dropbox, google, WeTransfer) and send link to mail address mentioned above

Reply to: LibRaw Project Goals and Objectives   1 week 6 days ago

Thanks.

:Jack

Reply to: LibRaw Project Goals and Objectives   1 week 6 days ago

meanwhile, we added list for 0.19 release (now in beta): https://www.libraw.org/supported-cameras#

Reply to: LibRaw Project Goals and Objectives   2 weeks 4 min ago

Supported camera list depends on compilation flags (availability of some decompression libraries), so we do not publish this list statically.
Application can obtain actual list via API Call: https://www.libraw.org/docs/API-CXX.html#cameraList
Also, simple_dcraw example with -L switch will print this list on output.

Reply to: LibRaw Project Goals and Objectives   2 weeks 13 hours ago

Hi...

Please accept my apology if this question is answered elsewhere - is there a list of all the digital cameras currently supported by LibRAW?

Thanks.

Reply to: Version 0.18.6 crashes constantly on Mac   3 weeks 2 days ago
Hi,

Hi,

do you mind to share the Mac and Win jni libraries to this community? :-D

Thanks

Reply to: 0.19.0-Beta2: replace use of auto_ptr with unique_ptr   1 month 21 hours ago

Thank you for the patch.

Too late for 0.19 (do not want to change ABI), but to be included in master branch (and, so, in next stable release)

Reply to: Crashes in 0.18.8 potentially due to Chinese metadata?   1 month 1 day ago

Unfortunately, we do not have any experience on ARM, all mobile apps uses LibRaw on own risk, we're unable to provide any support for this (no development toolchain, no emulators, nothing).

If you're able to get real file samples that produces repeatable problem (and the problem is reproducible on PC/Mac), please share samples with us (info@libraw.org). Without samples it is very hard to say anything.

We have some (limited) sales of our FastRawViewer (uses LibRaw, of course) to Chinese users and there is no chinese-specific bug reports.

Reply to: Fuji X-T2 raw decode speed difference between half and full   1 month 3 days ago

Thanks -- very helpful!

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   1 month 3 days ago

I agree this is a much better fix and will apply it to my copy. Thanks!

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   1 month 3 days ago

And, yes, this points to two-part structure: pointers table + additional jump buffer.

I do not see anything bad here.

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   1 month 3 days ago

Agree, it may fail in bad loop here. To be fixed in beta2

return definitely needed here, also error should be indicated by
T.tformat = LIBRAW_THUMBNAIL_UNKNOWN;

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   1 month 3 days ago

With respect to cinfo.err, the current code does work.

However, if you look at the definition of cinfo.err in libjpeg, it is assumed to be a pointer to a structure that contains function pointers for the error handler, exit handler, etc. The cerr pointer you pass in has that structure as its first part, but then also has a jmp_buf structure following this structure as the second part.

Somehow to my mind it is cleaner to have cinfo.err point to a "pure" function pointers block, and use cinfo.client_data to point to the jmp_buf structure. But to each his own.

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   1 month 3 days ago

You still need the return statement, otherwise if jpeg_create_decompress fails, won't it fail again after the longjmp?

Pages