Problem with DNG SDK & GPR SDK

[Jamaika1]

NOTES
I. GPR SDK comes with (patched) Adobe DNG SDK source (v1.4 but outdated).
This DNG SDK is NOT compatible with LibRaw since 0.20 due to
internals change:
- (older) DNG SDK 1.4 uses static arrays for IFDs/ChainedIFDs
- (actula) DNG SDK 1.5 uses std::vector for those
Although change is minor, we do not see any way to distinguish two
versions at compile time.

II. So, you need to patch actual Adobe DNG SDK v1.4 (dated 2015)
(most likely, this apply for v1.5 _too)

I added gopro .diff corrections. Unfortunately photos don't want to be created.
My commands and added libraries are below
for %%f in ("dng_*.cpp") do g++.exe -std=gnu++11 -ftree-vectorize -g0 -O3 -fPIC -D_DEBUG -DWIN32 -DqWinOS=1 -DqDNG64Bit=1 -DWINVER=0x0601 -D_WIN32_WINNT=0x0601 -DqDNGValidateTarget=1 -DqDNGUseConditionVariable=1 -DqDNGThreadSafe=1 -DWIN_ENV=1 -DNDEBUG -DLIBRAW_NODLL -DXMP_StaticBuild=1 -DBanAllEntityUsage -DXML_STATIC -DSUPPORT_SHARED_POINTERS_IN_STD=1 -DNO_PTHREAD=1 -DLIBRAW_USE_OPENMP=1 -DUSE_GPRSDK=1 -DUSE_DNGSDK=1 -DUSE_X3FTOOLS=1 -DUSE_6BY9RPI=1 -DNLIBRAW_USE_AUTOPTR=1 -DUSE_ZLIB=1 -DUSE_JPEG=1 -DUSE_JASPER=1 -DUSE_LCMS2=1 -DBITS_IN_JSAMPLE=8 -DEXCLUDE_MIF_SUPPORT -DEXCLUDE_PNM_SUPPORT -DEXCLUDE_BMP_SUPPORT -DEXCLUDE_RAS_SUPPORT -DEXCLUDE_JP2_SUPPORT -DEXCLUDE_JPG_SUPPORT -DEXCLUDE_PGX_SUPPORT -DINLINE=__inline -DLOCAL(type)="static type" -c %%f -o %%~nf.o
https://github.com/Jamaika1/dng_sdk_1.5.1_-_gpr_sdk_1.0.0

dcraw_emu.exe -v -o 0 -T -g 1.0 4.5 GOPR0024.GPR

Cannot unpack GOPR0024.GPR: Corrupted data or unexpected EOF

[LibRaw]

to make sure the problem is not with GPR file, could you please share it?

[Jamaika1]

No problem
https://www.sendspace.com/file/qcuwn6
Source images are in Gopro GPR library.

[cgilles]

Hi,

I vote also for a backward DNG sdk compatibility. In digiKam we still use DNG 1.3 and libraw 0.20.0-beta1 do not compile with it.

Note : i tried to update to last DNG 1.5, and changes are not small. I successfully compile digiKam with 1.5 in a dedicated branch but It crash quickly at DNG processing calls. So we will still under 1.3 for a while until we found the problem in implementation.

Best Regards

Gilles Caulier

[LibRaw]

@cgilles, this is not possible: we've implemented additional possibilities when dealing w/ DNG files (LIBRAW_PROCESSING_DNG_ADD_ENHANCED, LIBRAW_PROCESSING_DNG_ADD_PREVIEWS, LIBRAW_PROCESSING_DNG_PREFER_LARGEST_IMAGE flags, also Stage2/stage3 processing)

If LibRaw is compiled w/ DNG SDK, it uses dng_info data fields to find specific IFD and extract/process specific subframe.

LibRaw relies on (modern) DNG SDK 1.4/1.5 internals. May be we'll support (old version of) DNG 1.4, we definitely have no plans for older versions support.

BTW DNG 1.4 was released 8 years ago (1.3 is 11 years old), time to move forward.

[LibRaw]

@Jamaika1, dcraw_emu binary is hardly useful without debug symbols.

So, could you please see yourself what decoder is called for GPR file.

[sandymc]

Giles, yes, for what it's worth I had major problems updating my software to the new versions of the DNK SDK; my experience was that the way Adobe have used C++ vectors, etc is C++ version dependent. So you have to play around with C++ dialects and library versions. Although, once I got it to compile, there were no run-time issues.

[LibRaw]

Finally: (older) DNG SDK 1.4 (dated May 2012) and (modern) DNG 1.4 (dated June 2015) have different dng_info fields (older one do not have fChainedSubIFD array).

So, implementing right sub-IFD search using old one will require full-scale testing (already performed for newer version compatibility). It's not worth time wasted: DNG 1.4 is very stable (no problem reports right now) and available from Adobe.

I do not close the issue right now, but I do not know how I could help:

• DNG SDK 1.4 + GPR SDK + provided patches are fully functional. This combo is used in our software (FastRawViewer/RawDigger) by many users under MacOS/macOS and Windows, using gcc, clang and visual studio compilers (different versions). The patches are created from real working repository.
• I do not know for what 'for %%f in ("dng_*.cpp") do g++.exe.... ' is used for, so could not help with it.

It may be useful to run debugger to narrow the problem search.

[LibRaw]

Updated DNG/GPR readmes with latest findings: 21641da

[Jamaika1]

So, could you please see yourself what decoder is called for GPR file.

I don't know what's going on. Does converter not select decoder by default for GoPro?
I added dngsdk decoder for GoPro. I have half the battle.
Are the colors correct? I don't know how to preview the original. For me they are matte.

dcraw_emu.exe -v -o 0 -dngsdk -T -g 1.0 4.5 GOPR0024.GPR
*** Warning: Too little padding on left edge of CFA image (possible interpolation artifacts) ***
*** Warning: Too little padding on top edge of CFA image (possible interpolation artifacts) ***
*** Warning: Too little padding on right edge of CFA image (possible interpolation artifacts) ***
*** Warning: Too little padding on bottom edge of CFA image (possible interpolation artifacts) ***
Writing file GOPR0024.GPR.tiff

[LibRaw]

Warnings are from DNG SDK if built with qDNGValidate defined

GoPro DNG (GPR) files have defaultcrop* tags set to full active area, that's why DNG SDK worries

[LibRaw]

BTW, it looks like you're succeeded w/ LibRaw + DNG + GPR combo. Can I close the issue, or something else need to be clarified?

[Jamaika1]

In my opinion, this requires further refinement. To use the free conversion of libRAW from source image to tiff, it is recommended to buy Adobe Photoshop.

[olegvakulenko]

@Jamaika1
If I understand correctly, you figured out how to compile a library with support for GPR files. Could you please share the detailed instructions on how to do this to me too, because my knowledge, unfortunately, is not enough to do everything myself and get the executable files.
Thanks!

[Jamaika1]

Please visit the doom9 forum
http://forum.doom9.org/showthread.php?t=174300&page=15
https://community.adobe.com/t5/camera-raw/adobe-dng-sdk-1-6/m-p/10712341?page=1