So when you say daylight colour profile, its a preset that comes with libraw vs what the camera thinks it should be? is there any reason the derived values should be more correct than the makernote values?
Quote from my last reply in that thread:
1st: the backtraces points to LibRaw::LibRaw (constructor), so the problem is not related to any specific RAW file
2nd: I've tried XCode 6, XCode 8, XCode 9 builds (using make -f Makefile.dist) and was unable to reproduce the problem using both dcraw_emu (single thread) and half_mt (multithreaded). Both samples works fine with DSC_1796.NEF sample (link above). The sample was multiplied into many (same) files: DSC_1796-[0-9].NEF
So, I'm still suspect that this is not LibRaw problem, but not enough stack problem. LibRaw objects are big (e.g. several 16-bit curves), so default stack size could be not enough (it is better to allocate LibRaw object dynamically to avoid that).
Is there any way to see is enough stack space is present [in your app]?
Sorry I think I misunderstood.
The problem is because the error I cannot compile the lib to test it. I thought you told me by removing the flag it would be ok.
Sorry,
Also, I took a look to the code of libtiff that is also included in msys2:
#ifdef __WIN32__
#include <windows.h>
/*
* Open a TIFF file with a Unicode filename, for read/writing.
*/
TIFF*
TIFFOpenW(const wchar_t* name, const char* mode)
{
static const char module[] = "TIFFOpenW";
int m, fd;
int mbsize;
char *mbname;
TIFF* tif;
m = _TIFFgetMode(mode, module);
if (m == -1)
return ((TIFF*)0);
This code line is because some (old) versions of MinGW does not support wide chars in file opening interface.
If that has changed, this line should be changed too (with compiler/runtime/whatever version check).
We're open to contributions, so if you could investigate the problem in depth (what versions/runtimes works with wchar_t and what is not), just propose patch.
Alternatively, you may create own Libraw datastream implementation and pass it to LibRaw.
Almost every camera employs anti-aliasing; that'd seem to =>approximately<= result in DNGs with one-quarter the effective pixel count, and color artifacts possibly(!) eliminated or greatly reduced—since that is of course the REASON for AA.
Gaussian blur should give a weak approximation of AA. For example, light falling on the top-left (Red) pixel wouldn't be shared with its upper and leftwards neighbors under AA; it'd all go to green & blue pixels that're right and down (in the common arrangement) from the Red.
But Gaussian blur would send a fraction of its light to all 8 Green + Blue neighbors, while reducing the light attributed to the original Red pixel. In that sense, there could be excessive fuzzing of the artificial image versus what a perfect lens + AA filter would produce.
some camera records four multipliers, while some (RGB/3 color) may use only three. In the second case, the cam_mul[1] (Green) should be copied to cam_mul[3] ('second green')
After that, cam_mul[] is usually normalized (i.e. divided to smallest value, so [1500,1000,1200,1000] will become [1.5,1,1.2,1])
And, yes, then color channels are multiplied to cam_mul[color] values.
unfortunately, we could not help. LibRaw Python bindings (rawpy) is not our product, so we completely do not know what is 'black_level_per_channel' vector (and other variables you mentioned)
sorry but that doesn't really answer the question
Unless your scene is lit by exact D65 (imaginary) light source, both values are 'not correct'
So when you say daylight colour profile, its a preset that comes with libraw vs what the camera thinks it should be? is there any reason the derived values should be more correct than the makernote values?
Derived D65 multipliers are calculated from daylight color profile, while makernotes multipliers are recorded by camera.
Thank you for confirming that.
Yes, LibRaw(0.19) object is significantly larger than (0.18). Looks like we need to move curve[0x1000] to dynamic allocation to save stack.
It was a stack problem. The memory footprint must have changed from 0.18.x to 0.19.
So, please close the issue.
There is very similar report related to digiKam: https://github.com/LibRaw/LibRaw/issues/186
Quote from my last reply in that thread:
1st: the backtraces points to LibRaw::LibRaw (constructor), so the problem is not related to any specific RAW file
2nd: I've tried XCode 6, XCode 8, XCode 9 builds (using make -f Makefile.dist) and was unable to reproduce the problem using both dcraw_emu (single thread) and half_mt (multithreaded). Both samples works fine with DSC_1796.NEF sample (link above). The sample was multiplied into many (same) files: DSC_1796-[0-9].NEF
So, I'm still suspect that this is not LibRaw problem, but not enough stack problem. LibRaw objects are big (e.g. several 16-bit curves), so default stack size could be not enough (it is better to allocate LibRaw object dynamically to avoid that).
Is there any way to see is enough stack space is present [in your app]?
OK, I got it. Thank you.
Makefile.mingw already defines -DLIBRAW_NODLL, so disabling DllDef (and, of course, DLL builds):
DllDef is defined in libraw_types.h:
#ifdef WIN32
#ifdef LIBRAW_NODLL
#define DllDef
#else
#ifdef LIBRAW_BUILDLIB
#define DllDef __declspec(dllexport)
#else
#define DllDef __declspec(dllimport)
#endif
#endif
#else
#define DllDef
#endif
Sorry I think I misunderstood.
The problem is because the error I cannot compile the lib to test it. I thought you told me by removing the flag it would be ok.
Sorry,
I can not understand the question. What feature you want to disable?
Also, I took a look to the code of libtiff that is also included in msys2:
#ifdef __WIN32__ #include <windows.h> /* * Open a TIFF file with a Unicode filename, for read/writing. */ TIFF* TIFFOpenW(const wchar_t* name, const char* mode) { static const char module[] = "TIFFOpenW"; int m, fd; int mbsize; char *mbname; TIFF* tif; m = _TIFFgetMode(mode, module); if (m == -1) return ((TIFF*)0);OK thanks. Can I disable that ?
Makefile.mingw builds LibRaw with -DLIBRAW_NODLL, so DllDef is defined empty
OK I will try to investigate, but I tried to compile libraw on MSYS2 with no sucess.
I've a lot of
This code line is because some (old) versions of MinGW does not support wide chars in file opening interface.
If that has changed, this line should be changed too (with compiler/runtime/whatever version check).
We're open to contributions, so if you could investigate the problem in depth (what versions/runtimes works with wchar_t and what is not), just propose patch.
Alternatively, you may create own Libraw datastream implementation and pass it to LibRaw.
Could you please provide more detailed bracktrace to see what line in LibRaw constructor caused that?
I do not see any incorrect code in quoted line. Could you please provide some additional data (e.g. stacktrace?)
HEIC is not raw format, but processed image format (similar to JPEG)
Almost every camera employs anti-aliasing; that'd seem to =>approximately<= result in DNGs with one-quarter the effective pixel count, and color artifacts possibly(!) eliminated or greatly reduced—since that is of course the REASON for AA.
Gaussian blur should give a weak approximation of AA. For example, light falling on the top-left (Red) pixel wouldn't be shared with its upper and leftwards neighbors under AA; it'd all go to green & blue pixels that're right and down (in the common arrangement) from the Red.
But Gaussian blur would send a fraction of its light to all 8 Green + Blue neighbors, while reducing the light attributed to the original Red pixel. In that sense, there could be excessive fuzzing of the artificial image versus what a perfect lens + AA filter would produce.
(Happy to be corrected on this, btw)
some camera records four multipliers, while some (RGB/3 color) may use only three. In the second case, the cam_mul[1] (Green) should be copied to cam_mul[3] ('second green')
After that, cam_mul[] is usually normalized (i.e. divided to smallest value, so [1500,1000,1200,1000] will become [1.5,1,1.2,1])
And, yes, then color channels are multiplied to cam_mul[color] values.
Dear Sir,
unfortunately, we could not help. LibRaw Python bindings (rawpy) is not our product, so we completely do not know what is 'black_level_per_channel' vector (and other variables you mentioned)
LibRaw does not saves RAW files (inc. DNG), consider Adobe DNG SDK for that.
Here is the patch for 2000D/4000D: https://www.dropbox.com/s/erxiu7f63c4qao9/2000d.patch?dl=0
clipping is necessary to avoid 'pink clouds' problem
Pages