For -H 2 and -H 9 the results are bitwise the same for dcraw and dcraw_emu (from 0.13.5) and my sample image (something with blown clouds)

The difference may be in auto-maximum feature in LibRaw (very useful for some cameras). To turn this feature off use -c 0 switch when running dcraw_emu:

dcraw_emu -c 0 -H 2

four_color_rgb value is saved in the beginning of dcraw_process() call, may be changed by half_size setting, but restored again at the end of dcraw_process(), just before return. (LibRaw 0.13.5)

Could you please provide sample code with errorneous four_color_rgb/half_size behaviour?

Thanks for report, to be tested.

Sorry for delayed answer, summer is vacation time.

Well, those comments are for raw converter developers.

Iliah, You say "It looks like the time spent in postprocessing to get more details and counter-act artifacts might be better spent if demosaicking prepares a cleaner and more detailed image to start with. The processing time difference between integer and floating point implementations of demosaicking most of the times is less than 5 seconds, which is substantially less compared to the time spent on image editing to get close to the same result. Try it, and you will see. "

How does one go about "trying it" to see? What about this comment:
"For float data output we need to change entire processing pipeline to floating point." from http://www.libraw.org/about?

Elle Stone

Take a look at the method "LoadRawImage" at https://valelab.ucsf.edu/svn/micromanager2/trunk/DeviceAdapters/Tethered... )

The problem is very simple:
- you have set half_size=1 *after* unpack is called. So for the very first run the half_size is not set for unpack stage but set for postprocessing stage.

But half_size option is heavily used on unpack() stage (only 1/4 of image array allocated, pixel data placement is very different).

You need to move
rawProcessor_.imgdata.params.half_size = 1;
line above of unpack() call.

I'm using LibRaw 0.13.1. I've tested on Windows and macosx; and in each case there is a difference between the first and the second decoded image.

#ifdef WIN32
// suppress sprintf-related warning. sprintf() is permitted in sample code
#define _CRT_SECURE_NO_WARNINGS
#endif
 
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <math.h>
#include <ctype.h>
#ifndef WIN32
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <sys/time.h>
#endif
 
#include "libraw/libraw.h"
#ifdef WIN32
#define snprintf _snprintf
#include <windows.h>
#endif
 
 
void write_ppm(libraw_processed_image_t *img, const char *basename)
{
    if(!img) return;
    // type SHOULD be LIBRAW_IMAGE_BITMAP, but we'll check
    if(img->type != LIBRAW_IMAGE_BITMAP) return;
    // only 3-color images supported...
    if(img->colors != 3) return;
 
    char fn[1024];
    snprintf(fn,1024,"%s.ppm",basename);
    FILE *f = fopen(fn,"wb");
    if(!f) return;
    fprintf (f, "P6\n%d %d\n%d\n", img->width, img->height, (1 << img->bits)-1);
/*
  NOTE:
  data in img->data is not converted to network byte order.
  So, we should swap values on some architectures for dcraw compatibility
  (unfortunately, xv cannot display 16-bit PPMs with network byte order data
 
#define SWAP(a,b) { a ^= b; a ^= (b ^= a); }
    if (img->bits == 16 && htons(0x55aa) != 0x55aa)
        for(unsigned i=0; i< img->data_size; i+=2)
            SWAP(img->data[i],img->data[i+1]);
#undef SWAP
*/
    fwrite(img->data,img->data_size,1,f);
    fclose(f);
}
 
int main(int argc, char *argv[])
{
	char filename[] = "raw_canon_550d.cr2";
	LibRaw rawProcessor_;
	int rc;
	for (int i = 0; i < 10; i++)
	{
		libraw_processed_image_t* rawImg = NULL;
		rc = rawProcessor_.open_file(filename);
		rc = rawProcessor_.unpack();
		rawProcessor_.imgdata.params.filtering_mode = LIBRAW_FILTERING_AUTOMATIC;
		rawProcessor_.imgdata.params.output_bps = 16; // Write 16 bits per color value
//		rawProcessor_.imgdata.params.gamm[0] = rawProcessor_.imgdata.params.gamm[1] = 1.0; // linear gamma curve
//		rawProcessor_.imgdata.params.no_auto_bright = 1; // Don't use automatic increase of brightness by histogram.
		rawProcessor_.imgdata.params.document_mode = 0; // standard processing (with white balance)
		rawProcessor_.imgdata.params.use_camera_wb = 1; // If possible, use the white balance from the camera.
		rawProcessor_.imgdata.params.half_size = 1;
		rc = rawProcessor_.dcraw_process();
		rawImg = rawProcessor_.dcraw_make_mem_image(&rc);
		char ppmfname[128];
		snprintf(ppmfname,1024,"%04i",i);
		write_ppm(rawImg, ppmfname);
		rawProcessor_.dcraw_clear_mem(rawImg);
		rawProcessor_.recycle();
	} 
	return 0;
}
//not truncated

Is is possible, that ESDK memory is protected from outside access and only ESDK call may use it?

Unfortunately, I've no reply from Canon-Europe yet, so cannot look into ESDK.

Good news.
If i use my memory to dowload cr2 file with edsdk, i haven't crash :D

thanks.