use
libraw_processed_image_t *image = RawProcessor.dcraw_make_mem_image(&ret);
to make 3-channel RGB image (output_bps should be set to 8 for JPEG)

and
LibRaw::dcraw_clear_mem(image);
to clean (deallocate) libraw_processed_image_t after JPEG creation is done.

Alex,
I don't know how to program in C or C++. I rely on being able to access LibRaw using either the C getters/putters or an executable. Accessing the libraw_rawdata_t structure is not available via the C getters/putters.

Peter

Alex,
I should have explained that I program in a language call LabVIEW. It has very limited ability to interact with LibRaw. The only method available is to use calls to the dll which is why I am trying to use the C setter/getters. If I could determine the pointer to the libraw_output_params_t structure I might be able to write to the structure but I see a long road ahead of me if I go down that road.

I need access to the RAW RGGB data for my astronomy image calibration application which I had based on
"DCRAW -v -D -4 -T filename" and am now trying to migrate to LibRaw. I suspect the quickest way for me to proceed is to use the example 4channels.exe. Do you agree or it there another way to proceed?

Yes I know: I wrote “understand” instead of “guess”, because I was trying to fix the thing in one time, instead of by instalments . Then:
I’ve read that a raw file stores exposition (E) values linearly, and that a GAMMA function can be applied to them during raw conversion in order to increase the range of pixel values in the lower zones of exposition. This last result can be achieved if E values have not yet been rounded to nearest integers, otherwise the GAMMA application adds no information about these zones. As a first step, could you tell whether or not you agree on this point?

Many thanks. From your answer, I understand that a camera applies the “GAMMA” function (with gamma 2.2, I suppose) to the inside-registered exposure values and converts them to integer numbers. No common user of a common digital camera can access the original exposure values in order to apply a different gamma and enhance the number of pixel levels in a low-exposure zone. Is this right? And does it also apply to any user, and any camera?

readme replenished, register keyword removed: https://github.com/LibRaw/LibRaw/commit/e53e15c72e630d6478f30e8c2c90ace9...

I managed to build gpr and libraw against Adobe's stock dng sdk v1.5. It seems to work. In case someone else needs this:

I: Build gopro/gpr:

1. replace gopro's toplevel CMakeLists.txt with this one (this builds only a subset of the libraries):
------------------------------------
# minimum required cmake version
cmake_minimum_required( VERSION 3.5 FATAL_ERROR )

set(CMAKE_SUPPRESS_REGENERATION true)
set(CMAKE_C_FLAGS "-std=c99")

# project name
project( gpr )

option(DNGINCLUDEDIR "Adobe DNG toolkit include directory")
INCLUDE_DIRECTORIES( ${DNGINCLUDEDIR} )

# DNG toolkit requires C++11 minimum:
set_property(GLOBAL PROPERTY CXX_STANDARD 17)

# add needed subdirectories
add_subdirectory( "source/lib/common" )
add_subdirectory( "source/lib/vc5_common" )
add_subdirectory( "source/lib/vc5_decoder" )
add_subdirectory( "source/lib/gpr_sdk" )

set_property(TARGET gpr_sdk PROPERTY CXX_STANDARD 17)

IF (WIN32)
TARGET_COMPILE_DEFINITIONS( gpr_sdk PUBLIC -DqWinOS=1 -DqMacOS=0 -DqLinux=0)
ELSEIF (APPLE)
TARGET_COMPILE_DEFINITIONS( gpr_sdk PUBLIC -DqWinOS=0 -DqMacOS=1 -DqLinux=0)
ELSE()
TARGET_COMPILE_DEFINITIONS( gpr_sdk PUBLIC -DqWinOS=0 -DqMacOS=0 -DqLinux=1)
ENDIF()
----------------------------------------

2. apply the two patches of README.GoPro.txt section II b.
the patch of section IIa is not needed with libdng1.5.

3. delete these two files:
/source/lib/gpr_sdk/private/gpr.cpp
/source/lib/gpr_sdk/private/gpr_image_writer.cpp

4. run CMAKE with -DDNGINCLUDEDIR, pointing to the headers from Adobe dng 1.5.

5. build. You get 4 libraries "gpr_sdk", "vc5_common", "vc5_decoder", "common", the rest is ignored.

II build libraw:
1. pass the following to ./configure:
CXXFLAGS="-stdlib=libc++ -std=c++17" CPPFLAGS="-DUSE_DNGSDK -DUSE_GPRSDK"
(and also add -I... for the header paths of the dng library and gopro's headers)

2. remove the 'register' keyword from these files:
src/utils/phaseone_processing.cpp
src/x3f/x3f_parse_process.cpp

Or probably -std=c++11 should work as well. dng1.5 seems to require c++11 at least.

Thanks, that clarifies things. I'll give it a try.

BTW, you may not include gpr_sdk/private/gpr.cpp in your gpr_sdk build, LibRaw do not use this high level interface.

(looks like we need to update GPR readme)

We are integrating it now.

I've checked this commit (using Qt Creator/libraw.pro build file).

OK, it looks like that relying that MinGW does not defines WIN32, but defines _WIN32 only is not correct. This assumption is fixed in this commit: https://github.com/LibRaw/LibRaw/commit/0ebd8a4e1846a3d265f823ac9b2f52ed...

(just use git pull to updated from github).

Checked w/ MinGW-W64/7.30, I do not see any problems