Skipped lines in Raw-Processing

Submitted by DragonTEC on

Hi everybody,

i've got a strange issue:

When i load a raw file (dng, converted via Lightroom from canon cr2), process it and try to save it into jpg, every like 175-200 lines are skipped, so the overall image has less height and the rest is filled with black.

A sample of what I'm talking about: http://art.untested.de/private/blub.jpg

what i'm basically doing is (error checking and other stuff ommitted for readability):

LibRaw rawProcessor;
rawProcessor.open_file(av[1]);
rawProcessor.unpack();
rawProcessor.dcraw_process();
int raw_width, raw_height, raw_color, raw_bitsize;
rawProcessor.get_mem_image_format(&raw_width, &raw_height, &raw_color, &raw_bitsize);
unsigned char *buffer = new unsigned char[raw_height * raw_width * 3];
rawProcessor.copy_mem_image(buffer, raw_width * 3, 0);
write_JPEG_file("blub.jpg",60,buffer,raw_width,raw_height); //jpg saving using libjpeg stuff

The write_JPEG function works perfectly. I tested it with filling the buffer with a gradiant and don't see any line skipping.

Additionally, when i try to use the data from the imgdata.image array instead of the copy_mem_image function to fill the buffer, i'm seeing the same line skipping, so this seems to be an issue with libraw. (or i'm forgetting something in the code.

Does anybody have an idea what is going wrong here or can provide a more advanced code sample? My ultimate goal is to have an array of 12 or 14 bit RGB-x-y-values to work with, and the provided samples are not very helpful with this and i can't find any other code anywhere..

Oh yeah, and some other bugs:

1) the wchar_t bug when compiling on windows / mingw is still present with 0.15-beta2. Because of this i'm still using 0.14.7
2) My .imgdata.rawdata.color_image array is never filled and gives me segfaults. the .rawdata.raw_image data is fine, though.

Forums: 

I investigated the issue

Submitted by DragonTEC on

I investigated the issue further and dumped the raw bayer values from .imgdata.rawdata.raw_image. The issue i described above is already present in the bayer data itself, so i assume the problem lies in the unpack function and not in the furthor processing.

Solution

Submitted by DragonTEC on

Found out this is an issue with <=0.14-7 and is fixed since 0.15-alpha1 because of using the 9.17th version of dcraw..

Also kind of fixed my mingw compiling issue with 0.15-beta2: MinGw also defines the WIN32 flag resulting in using the not existing wchar_t type. I had to throw out theese defines in like 5 source files to fix this but now it works.. so what i basically would advice is to change the check if WIN32 is defined into ( WIN32 && !MINGW ).. then it should compile without issues..

This issue should be fixed in

Submitted by lexa on

This issue should be fixed in 0.15-Beta2 and later:

#if defined(WIN32) && !defined(__MINGW32__)
	virtual const wchar_t* wfname(){ return NULL;};
	virtual int         subfile_open(const wchar_t*) { return -1;}
#endif

-- Alex Tutubalin @LibRaw LLC

LightRoom 'fast load' DNGs

Submitted by lexa on

LightRoom 'fast load' DNGs are supported only in LibRaw 0.15

-- Alex Tutubalin @LibRaw LLC