Ah yes, the problem is fixed!

Will this be fixed in LibRaw? I guess I'll have to wait for the next public snapshot?

Thanks
Joost

I'm building the DNG SDK using cmake and this CMakeLists.txt. This creates a static library, on Windows, Linux and macos.

cmake_minimum_required(VERSION 3.15)
project(dng)
 
INCLUDE_DIRECTORIES( ${JPEG_INCLUDE_DIR} )
ADD_DEFINITIONS( ${JPEG_DEFINITIONS} )
 
INCLUDE_DIRECTORIES( ${ZLIB_INCLUDE_DIR} )
ADD_DEFINITIONS( ${ZLIB_DEFINITIONS} )
INCLUDE_DIRECTORIES( ${JXL_INCLUDE_DIR} )
ADD_DEFINITIONS( ${JXL_DEFINITIONS} )
INCLUDE_DIRECTORIES( ${XMP_INCLUDE_DIR} )
ADD_DEFINITIONS( ${XMP_DEFINITIONS} )
 
FILE(GLOB SRCFILES ${CMAKE_CURRENT_SOURCE_DIR}/dng_sdk/source/*.cpp)
FILE(GLOB HFILES ${CMAKE_CURRENT_SOURCE_DIR}/dng_sdk/source/*.h)
ADD_LIBRARY(dng-sdk STATIC ${SRCFILES})
 
TARGET_INCLUDE_DIRECTORIES( dng-sdk INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/source )
SET_TARGET_PROPERTIES(dng-sdk PROPERTIES PUBLIC_HEADER "${HFILES}")
 
set_property(TARGET dng-sdk PROPERTY CXX_STANDARD 17)
 
TARGET_COMPILE_DEFINITIONS( dng-sdk PUBLIC
                            -DqDNGThreadSafe=0
                            -DqDNG64Bit=1
                            -DqDNGDebug=0                      # do not compile debug code
                            -DqDNGValidateTarget=0             # do not build dng_validate-binary
                            -DqDNGUseLibJPEG=1                 # use libjpeg
                            -DqDNGXMPFiles=0 -DqDNGXMPDocOps=0 # build minimal XMP-set
                            -DqDNGUseStdInt=1                  # Must be set to 1, else do not compile under Linux.
)
 
# Check processor endianness (todo: not sure bigEndian platforms are set correctly)
INCLUDE(TestBigEndian)
TEST_BIG_ENDIAN(IS_BIG_ENDIAN)
IF(NOT IS_BIG_ENDIAN)
    TARGET_COMPILE_DEFINITIONS( dng-sdk PUBLIC -DqDNGLittleEndian=1)
ENDIF(NOT IS_BIG_ENDIAN)
 
IF (WIN32)
    if(MSVC)
        TARGET_COMPILE_OPTIONS( dng-sdk PRIVATE /GR /EHsc)
    else()
        TARGET_COMPILE_OPTIONS( dng-sdk PRIVATE -fexceptions)
    endif()
    TARGET_COMPILE_DEFINITIONS( dng-sdk PRIVATE -DqWinOS=1 -DqMacOS=0 -DqLinux=0 -DWIN_ENV -DWIN32 -D_WINDOWS)
ELSEIF (APPLE)
    TARGET_COMPILE_OPTIONS( dng-sdk PRIVATE -fexceptions )
    TARGET_COMPILE_DEFINITIONS( dng-sdk PRIVATE -DqWinOS=0 -DqMacOS=1 -DqLinux=0 -DMAC_ENV)
ELSE()
    TARGET_COMPILE_OPTIONS( dng-sdk PRIVATE -fexceptions -fPIE)
    TARGET_COMPILE_DEFINITIONS( dng-sdk PRIVATE -DqWinOS=0 -DqMacOS=0 -DqLinux=1 -DUNIX_ENV)
ENDIF()
 
install(TARGETS dng-sdk DESTINATION lib PUBLIC_HEADER DESTINATION include)

I'm using the latest RawDigger, 1.4.9 Release Build 821 (ARM64).

Here are 2 screenshots from Adobe camera raw, showing identical colors when using 'As Shot':

https://drive.google.com/file/d/1GhtJUCtIGRBP4FbReq2Jdk5vvPpoKy8X/view?u...
https://drive.google.com/file/d/1skhE7-up6nEWymxM9JShH10mO4ucm3ZL/view?u...

We cannot provide support for components from other vendors. For all questions related to dng sdk please contact Adobe support.

As an exception for the rule above: to create Adobe DNG SDK library (shared or static) just create corresponding build target (static or shared library) in your build environment (MS VS, XCode, whatever...) with all Adobe DNG SDK sources excluding source/dng_validate.cpp

We managed to support JPEG-XL and Canon H265 previews in dcraw_make_mem_thumb via this patch/commit: https://github.com/LibRaw/LibRaw/commit/cc118c1c1869e2559dbd0c7639d21915...

That was it: I set adjust_maximum_thr = 0 and now my captures are consistent. Thanks very much!

It is hard to discuss something without having files in question on hands.

Probably: your Sony (!) images are shot in Small/Medium (pseudo)RAW mode. This is YCC files (similar to lossless JPEGs), already processed and white balanced in camera.

All looks good now, thanks very much!

Thanks for fixing that link. Source files and libraries are fine. However the /bin subfolder, normally containing executables such as dcraw_emu, is empty in LibRaw-0.21.3-macOS.zip aside from the .keep_me file.

Best Regards,
AJW

Thank you for your feedback

Fixed

Good morning, Alex.

github problems healed overnight.

So I could just pull the repository into a clean directory and run a fresh compile of libraw from master using your suggested simpler way to compile, which avoids configure before make.

make -f Makefile.dist

The created binary of static libraw.a is now usable and can be linked with no unresolved symbols from both master branch and also version 0.21.

My finding is:

The suggested way to compile the binaries using 'autoreconf --install' and 'configure' messed up the source repository and build pipeline specifically on our macos environment. For some unknown reason this ended up in an unusable binary of the static libraw library that could not be linked due to 'undefined symbols'.

I should add, that autoreconf/configure requires installation of additional tools using homebrew package manager on Mac, namely autoconf, automake and pkg-config, that are not part of the standard Apple development environment XCode. Seems these tools messed up detection of the proper C/C++ make configuration on mac platform which led to incompatibilities linking two different libraries (undefined symbols).

I rolled back to plain Apple XCode C/C++ development tools, and uninstalled autoconf & Co, before I tried a fresh install of libraw. That said, autoreconf/configure is not possible by using XCode only on Mac plaform.

Apologies, but I didn't dig deeper in analysis what exactly fails using autoreconf/configure on mac, thus cannot provide insights what could be improved for libraw to be installed the suggested way on macos Sonoma.

Avoiding the suggested installation to run autoreconf/configure to compile libraw static binary on mac Sonoma platform is the solution in my case.

Thanks again for your help.

Thilo

I do not see any problems with github:

lexa@macair ~ % mkdir test
lexa@macair ~ % cd test
lexa@macair test % git clone https://github.com/LibRaw/LibRaw.git
Cloning into 'LibRaw'...
remote: Enumerating objects: 18973, done.
remote: Counting objects: 100% (1280/1280), done.
remote: Compressing objects: 100% (527/527), done.
remote: Total 18973 (delta 884), reused 1065 (delta 751), pack-reused 17693 (from 1)
Receiving objects: 100% (18973/18973), 13.78 MiB | 21.22 MiB/s, done.
Resolving deltas: 100% (14748/14748), done.
lexa@macair test %

Also, I do not think that LibRaw will even build if git transaction is incomplete, assuming you're starting from scratch with empty folder. If the folder was not empty, it probably contains some previous version.