There is FC(row,col) function, which returns index (in 0..3) range of value within image[i][4].
Look in the samples/unprocessed_raw.cpp for usage example
You're right, that raw_image[row*col], than processed_image[row*col][3] may be better alternative. Sometimes in future, LibRaw may be refactored this way.
There is many reasons to have current memory allocation pattern:
* (main one) LibRaw derived from dcraw sources, so memory pattern is preserved
* there is some special cases (Foveon, Sinar 4-shot) where more than one component is needed, so 4-component image[] is more general and fits all cases.
* most LibRaw users uses post-processing stage too. With postprocessing there is no advantage in 2-phase allocation (one for raw data and one for postprocessing).
There is FC(row,col) function, which returns index (in 0..3) range of value within image[i][4].
Look in the samples/unprocessed_raw.cpp for usage example
You're right, that raw_image[row*col], than processed_image[row*col][3] may be better alternative. Sometimes in future, LibRaw may be refactored this way.
There is many reasons to have current memory allocation pattern:
* (main one) LibRaw derived from dcraw sources, so memory pattern is preserved
* there is some special cases (Foveon, Sinar 4-shot) where more than one component is needed, so 4-component image[] is more general and fits all cases.
* most LibRaw users uses post-processing stage too. With postprocessing there is no advantage in 2-phase allocation (one for raw data and one for postprocessing).