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?
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 )
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.
ok it all works but I had to use a different mingw compiler to get it all working
and even though it worked fine on the samples - my code which is based on the
samples was a bit fussy
I recommend using the latest compiler if on windows 10
1st option: the samples we have contains vital metadata (image size) in EXIF fields. It would not help if you just prepend arbitrary JPEG at start.
2nd option (backport from patched dcraw): looks OK, but there is a lot of code covering multiple cases. It is not possible to move on without having sample files for all these multiple cases.
We are ready to go this route, but someone should prepare (various) examples
The Raspberry Pi RAWs should be identical to the RAW data dumps in the JPEG file.
Look for "BRCMo" (Hex: 42 52 43 4d 6f) in your files. Thats where my files start.
Unfortunatelly I can only produce RAWs for my real use case. Maybe I could put fake JPEGs in front?
I have also to contact the people from DeepSkyStaker. The program loads EXIF(JPEG) files at start concatenated w/ RAW but only uses the JPEG ...
It looks like I have 2 possible options:
1st: Fake JPEG data in front of the RAW data and and fix the bug in DeepSkyStacker
2nd: Enable LibRaw to read the pure RAWs (here a fork of dcraw which should be able to do this: https://github.com/6by9/dcraw) and ask for a DeepSkyStacker update with the new Libraw.
R-Pi files we have (and support in LibRaw) is EXIF(JPEG) files at start concatenated w/ RAW data dump.
Your dump looks entirely different. Do you have any format docs?
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?
All out-of-camera RAW files are 'integer', not continuous
readme replenished, register keyword removed: https://github.com/LibRaw/LibRaw/commit/e53e15c72e630d6478f30e8c2c90ace9...
Thank you for detailed explanation, we'll add cmake/gpr related section to readme.gopro.
Note: register keyword results into warning, not error on c++11
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.
ok it all works but I had to use a different mingw compiler to get it all working
and even though it worked fine on the samples - my code which is based on the
samples was a bit fussy
I recommend using the latest compiler if on windows 10
Thanks, that clarifies things. I'll give it a try.
here it is: https://github.com/LibRaw/LibRaw/commit/54b8d6c0f4fbea3aab7a706d35370156...
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)
Sorry, we still use Adobe DNG SDK v1.4
We are integrating it now.
Supported in 201910 snapshot: https://www.libraw.org/news/libraw-snapshot-201910
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
I ran in to a syntax error at #endif /* _LIBRAW_CLASS_H */
This may not be the correct endif (the compiler says there is an extra ( or maybe an extra if
I think I have not repaired this correctly as my fix then causes a bunch of errors
in libraw_c_api.cpp
If I knew what I was doing this would be an easy fix
(should be) fixed in this commit: https://github.com/LibRaw/LibRaw/commit/fabd1482276cd3c0aed7b2a3cb9ba07c...
I just sent some example files to info at libraw dot com.
I hope you have access to this mailbox and that the examples are sufficient.
Different RAW files that covers different cases handled in patched dcraw.c you mentioned above.
How do these example files have to look like?
1st option: the samples we have contains vital metadata (image size) in EXIF fields. It would not help if you just prepend arbitrary JPEG at start.
2nd option (backport from patched dcraw): looks OK, but there is a lot of code covering multiple cases. It is not possible to move on without having sample files for all these multiple cases.
We are ready to go this route, but someone should prepare (various) examples
The Raspberry Pi RAWs should be identical to the RAW data dumps in the JPEG file.
Look for "BRCMo" (Hex: 42 52 43 4d 6f) in your files. Thats where my files start.
Unfortunatelly I can only produce RAWs for my real use case. Maybe I could put fake JPEGs in front?
I have also to contact the people from DeepSkyStaker. The program loads EXIF(JPEG) files at start concatenated w/ RAW but only uses the JPEG ...
It looks like I have 2 possible options:
1st: Fake JPEG data in front of the RAW data and and fix the bug in DeepSkyStacker
2nd: Enable LibRaw to read the pure RAWs (here a fork of dcraw which should be able to do this: https://github.com/6by9/dcraw) and ask for a DeepSkyStacker update with the new Libraw.
R-Pi files we have (and support in LibRaw) is EXIF(JPEG) files at start concatenated w/ RAW data dump.
Your dump looks entirely different. Do you have any format docs?
LibRaw is not about video files and/or (already) processed files.
LUMIX says:
HSP is a HDR format compressed with the HLG video technology.
HLG (Hybrid Log Gamma) is a HDR format following (ITU-R BT.2100.
Supported in 201910 snapshot: https://www.libraw.org/news/libraw-snapshot-201910
Thanks.
Does not looks like something well-known.
Are you sure this is really RAW (mostly unprocessed) file?
Pages