Accessing processed image data

Submitted by marekp on

I'm unsure how and where to access processed image data after calling libraw_dcraw_process. I noticed that imgdata.image now has a valid pointer, but looking at the 4channels samples that suggests that this is just raw data (which I can and do currently access via imgdata.rawdata.raw_image). I've also looked at calling libraw_dcraw_make_mem_image which seems to create reasonable values in libraw_processed_image_t (width, height, etc., ) but just has data as a byte array (despite 16bit processed data) length=1 (libraw_types.h has ''unsigned char data[1]" declaration). Should I be able to interpret this as ''unsigned char *data" and reconstruct 'ushort' from pair of bytes? Or am I missing something? I've looked through the samples, but most (all?) simply create the processed data (somewhere) and pass it (opaquely) to the file output functions.

Sorry if the questions are stupid - I'm very rusty on C++ these days and I'm trying to write a JNA wrapper for LibRaw.

Forums: 

Yes, data[1] is to make it

Submitted by lexa on

Yes, data[1] is to make it 'in place array' (no additional indirection level)

It is allocated via this code:

  int stride = width * (bps / 8) * colors;
  unsigned ds = height * stride;
  libraw_processed_image_t *ret = (libraw_processed_image_t *)::malloc(
      sizeof(libraw_processed_image_t) + ds);

-- Alex Tutubalin @LibRaw LLC

Thanks for quick reply.

Submitted by marekp on

Thanks for quick reply.
So can I assume that for 16bit RGB data the order of bytes will be:
pixel0-R-LSbyte, pixel0-R-MSbyte, pixel0-G-LSbyte, pixel0-G-MSbyte, pixel0-B-LSbyte, pixel0-B-MSbyte, pixel1-R-LSbyte, and so on?

You can assume that this is

Submitted by lexa on

You can assume that this is pixel0R, pixel0G, pixel0B.... each value is 16-bit unsigned integer datatype in your CPU byte order.

-- Alex Tutubalin @LibRaw LLC

Thank you!

Submitted by marekp on

Thank you!