Recent comments

Reply to: Request for software names   1 week 1 day ago

I originally wrote Rawshack in 2011 but have recently been updating it with new features. It's GPL v3 and runs on Windows, OSX, and Linux. Here's the home page:

http://testcams.com/rawshack/

Reply to: Output Color Options   1 week 6 days ago

Thanks for the additional information and openness Alex, much appreciated.

Reply to: Output Color Options   1 week 6 days ago

Yes, FastRawViewer uses LibRaw (+RawSpeed +Adobe DNG SDK) to decode raw data and its own (post)processing code (written in SSE3/AVX2 assembly for speed, that's why FRV is Fast)

RawDigger uses LibRaw (+libs listed above) for decoding and dcraw_process() (with bilinear 'demosaic', fast but far from perfect), because RGB rendering is only for user reference (we plan to change demosaic to own code in future releases to provide better rendering, because many users use RawDigger as raw processor :).

I'm not familiar with Apple Core Image. It is very likely it will accept (cropped?) imgdata.rawdata.rawimage[] as input to CIRawFilter (this is flat array of unprocessed raw values decoded from camera).

Reply to: Output Color Options   1 week 6 days ago

Thanks Alex. Given your reply, am I correct in assuming that applications like FastRawViewer are not using dcraw for processing and are instead using their own algorithms?

On a related note, in Apple's Core Image framework for macOS, they have a filter called CIRawFilter that can take RAW data as input. The header file states that the following formats are supported:

kCVPixelFormatType_14Bayer_GRBG, 
kCVPixelFormatType_14Bayer_RGGB, 
kCVPixelFormatType_14Bayer_BGGR, 
kCVPixelFormatType_14Bayer_GBRG

If I want to try and use Core Image for post-processing, is there a way to get the unprocessed image data from LibRaw in any of the formats listed above?

Reply to: Output Color Options   1 week 6 days ago

dcraw_process is derived (without any significant changes) from dcraw.c code
It is slow and image processing options are limited.

You may play with dcraw_emu sample and different command line options to get output that suits your needs. Each dcraw_emu command-line parameter translates into LibRaw.imgdata.params value.

Reply to: LibRaw threading requirements.   1 week 6 days ago

Oops, I didn't even think of that but, you're right. Allocating a new LibRaw object dynamically solves the problem. Thanks for the quick response and for your work on LibRaw.

Reply to: LibRaw threading requirements.   1 week 6 days ago

What is stack size in (GCD) background threads?

LibRaw objects are large, you may need to allocate it dynamically to save stack space.

Reply to: WB to Temp and Tint   2 weeks 3 days ago

In the previous post there was nonsense written. Another piece of code is:

inline void mul2temp_xyz_cam(double *cam_mul, double (*xyz_cam)[3], double &temp, double &tint, int colors = 3)
{
	double xyz[3] = {0,0,0};
	for (int i=0; i < 3; i++)
		for (int j=0; j < colors; j++)
			xyz[i] += xyz_cam[i][j] * 0.5/cam_mul[j];
	xyz2temp(xyz, temp, tint);
}
 
void mul2temp_cam_xyz(double *cam_mul, double (*cam_xyz)[3], double &temp, double &tint, int colors = 3)
{
	double inverse[4][3];
	double xyz_cam[3][3];
	pseudoinverse (cam_xyz, inverse, colors);
	for (int i=0; i < 3; i++)
		for (int j=0; j < colors; j++)
			xyz_cam[i][j] = inverse[j][i];
	mul2temp_xyz_cam(cam_mul, xyz_cam, temp, tint);
}
 
	int i, j, k;
	double xyz_cam[3][3];
	const double xyz_rgb[3][3] = {			// sRGB to XYZD65
		{ 0.412453, 0.357580, 0.180423 },
		{ 0.212671, 0.715160, 0.072169 },
		{ 0.019334, 0.119193, 0.950227 } };
	for (i=0; i < 3; i++)
		for (j=0; j < colors; j++)
			for (xyz_cam[i][j] = k=0; k < 3; k++)
				xyz_cam[i][j] += xyz_rgb[i][k] * rgb_cam[k][j]*pre_mul[j];
 
	mul2temp_xyz_cam(cam_mul, xyz_cam, temp, tint);

doesn't work too. Nevertheless it is not clear how to convert factors into Temp/Tint.

Reply to: Print out white balance coefficients   3 weeks 2 days ago

imgdata.color.pre_mul[] coeffs, but only after dcraw_process()

Reply to: Print out white balance coefficients   3 weeks 2 days ago
Hi,

Hi,

If I set "use_auto_wb" to 1, how can I retrieve the final set of white balance coefficients that is calculated by "libraw"? also, if I use "greybox" method to calculate the white balance coefficients, is there a variable through which I can get the final values?

Thanks a lot,

Mio

Reply to: Print out white balance coefficients   1 month 1 week ago

WB selection logic is in scale_colors() (this call will print multipliers if compiled with DCRAW_VERBOSE defined.
You may copy-paste this logic to your own call, or, if you do not use all possible ways to set WB coeffs, you may simplify it.

Reply to: Use of Rawspeed 2   1 month 1 week ago

RawSpeed master has transferred from Klaus Post to darktable team.
There are a *lot* of changes in this version, in particular it requires modern C++ and current version does not compile with MS Visual Studio (I have not tried, but developers says it).
This branch not tested by LibRaw team and there is no any timeframe for that ('later this year or next year').

So, you may try to use this version with LibRaw on you own risk. Most likely, you'll need to change something (in RawSpeed or in LibRaw or in both). Patches for LibRaw are welcome.

Reply to: Use of Rawspeed 2   1 month 1 week ago

Is this still the case? Should we still use the Rawspeed master branch instead of the develop branch?
The master branch hasn't been updated since 2014. The development branch was last updated in 11/2016.
Also...are you using
https://github.com/klauspost/rawspeed or
https://github.com/darktable-org/rawspeed ?

Reply to: DCRAW_MAKE_MEM_IMAGE   1 month 2 weeks ago

standard sequence for file processing:
open_file();
unpack();
dcraw_process();
dcraw_make_mem_image();

Reply to: List of supported cameras   1 month 2 weeks ago

Hello Alex,

thanks a lot that is perfectly fine! I just wasn't aware of that method. Thanks a lot!

Regards
Torsten

Reply to: List of supported cameras   1 month 2 weeks ago

This list updates so frequently, so we opted not publish this list, because it will require too frequent updates.

Actual camera list is available via LibRaw::cameraCount() and LibRaw::cameraList() calls ( https://www.libraw.org/docs/API-CXX.html#cameraList )

Also, samples/simple_dcraw will print total count if started w/o params, and will print the list if started with -L key

Reply to: Issue with Pentax *istD   1 month 3 weeks ago

Thanks a lot, issue confirmed

Reply to: ACES colorspace support   1 month 3 weeks ago

well I am not familiar with the code base. Just wanted to leave this here. Basically, the aces target space has the wrong primaries.

You should use:
// RGB = ACES: 0.7347,0.2653 0.0,1.0 0.0001,-0.0770
// White = D60: 0.32168,0.33767

but it seems that you are using
// RGB = ACESwork: 0.713,0.293,0.165,0.83,0.128,0.044
// White = D60: 0.32168,0.33767

hope this helps

Reply to: ACES colorspace support   1 month 3 weeks ago

Could you please suggest a patch to fix it (for dcraw, if you're not familiar with LibRaw source)

Reply to: ACES colorspace support   1 month 3 weeks ago

Hi,
I tested the new ACES Primaries implementation (in dcraw).
Looks like you are using the AP1 primaries rather than the AP0.
ACES is defined to use AP0 primaries for image exchange.

Hope that makes sense.
best
Daniele

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   1 month 3 weeks ago

It should do so:
LibRaw_memmgr raises exception (LIBRAW_EXCEPTION_ALLOC) if malloc/calloc/realloc fails.
This exception is caught on upper level and error code returned.

This will broke if you compile LibRaw without C++ exceptions support (or if C++ exceptions are broken in your compiler/runtime)

Reply to: libraw_dcraw_make_mem_image returns image with empty data size   1 month 3 weeks ago

After studying this problem a little more in detail, I noticed that the dcraw result failed if there was some memory fragmentation on the device. This seems to occur earlier with libraw then with dcraw (maybe because some additional allocations are made?). May it would be still possible to report clearer error when dcraw failed because of memory restrictions?

Regard Torsten

Reply to: libraw interface   1 month 3 weeks ago

So the -c is used for something else in Libraw. I am not successful in adding (VB Net 2015) a reference to LibRaw Dll
It just refuses to add it. I was not able to register it in Windows. So I am way off base Do I need anything more than the DLL? I wonder if there is anyone around who has actually done this. Just a bit of help would be good
Do I need to add anything more than the Dll My program finds and runs all the version emu, simple, etc but it wil lnt
pipe to memory
Help please

Its my lack of C (I am 80 and once used assembly language but not much C)

Reply to: Saturation   1 month 3 weeks ago

user_sat is documented way to change maximum with guarantee you do not break anything

(for example, if you'll change maximum value after open_file(), but before unpack() it can result into data error exceptions/warnings).

Reply to: Saturation   1 month 3 weeks ago

Thanks a lot. This is clear now. I can change the maximum. Just I can't imagine why and where it can be needed.

Pages