Recent comments

Reply to: Nikon NEF RAW data minimum value clamp   5 years 11 months 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   5 years 11 months 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   5 years 11 months 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   5 years 11 months ago

Nikon D5300 black level value seems to be 600

Reply to: About LibRaw   5 years 11 months ago

When I use DCRAW to extract the RAW values from my D5300 NEF files I notice that the minimum value for all pixels is clamped at 588. Does the NEF format store values below this 588 clamp? Is DCRAW simply clamping the values at 588 based upon some NEF documentation? I am an astrophotographer and this 588 clamp interferes with generating master BIAS and DARK frames.

Reply to: use_camera_wb   5 years 11 months 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   5 years 11 months 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   5 years 11 months 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: About LibRaw   5 years 11 months ago

Thanks.

:Jack

Reply to: About LibRaw   5 years 11 months ago

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

Reply to: About LibRaw   5 years 11 months 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: About LibRaw   5 years 11 months 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   5 years 12 months 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   6 years 5 days 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?   6 years 6 days 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   6 years 1 week ago

Thanks -- very helpful!

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   6 years 1 week 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   6 years 1 week 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   6 years 1 week 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   6 years 1 week 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   6 years 1 week ago

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

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   6 years 1 week ago

And 1st patch:

cinfo.err is pointer, it does not need to have 'space' for longjump, it just points to already allocated structure.

Reply to: Fuji X-T2 raw decode speed difference between half and full   6 years 1 week ago

Standard (no -q N) X-Trans interpolation is 3-pass Markesteijn method. Yes, it is slow (esp. compared with half demosaic)

Reply to: 0.19.0-Beta1: small fix in thumbnail generation code   6 years 1 week ago

JPEG thumbnails are provided as-is, libjpeg is used only to get channels count.
So, even if libjpeg fails, this does not mean bad thumbnail, calling app should test it (again)

Pages