You can integrate C-code in MATLAB using the mex-API. I looked at this for dcraw, but got stuck, and I found that it was simply less work to make a thin MATLAB wrapper calling dcraw from the command-line.
I remember some frustrating aspects of doing anything to the dcraw code, hope that this project makes it easier.
LibRaw (and, so, dcraw_emu) contains 'auto-maximum' feature to deal with 'pink clouds' problem.
If you want to produce files which are binary identical to dcraw's results, you should switch this option off. Use -c 0 switch of dcraw_emu to do that.
So, if your code crashes in ::free(), it should crash in LibRaw's free() too. For pointer allocated by ::malloc() there is no difference between LibRaw::free() and ::free().
I cannot reproduce this problem in my Windows enviroment (VS2008 SP1, Win7/x64).
Could you please describe your enviroment in more detail (VS2008 patch level, Windows version, may be sample code)?
P.S. Sorry for very aggressive captcha. This is the only way to prevent forum/comments spam.
Please note, that registered/authorized users are not terrorized by captcha :)
I also encounter this problem.
In my project I link the libraw (I use Visual Studio). Everything works fine.
However if I want to free (using ::free(ptr)) the pointer returned by dcraw_make_mem_image(...) I get an exception
_CrtIsValiHeapPointer(pUserData) documented in dbgheap.c with
/*
* If this ASSERT fails, a bad pointer has been passed in. It may be
* totally bogus, or it may have been allocated from another heap.
* The pointer MUST come from the 'local' heap.
*/
_ASSERTE(_CrtIsValidHeapPointer(pUserData));
I think the problem is caused that the lib is creating the memory, so only the lib itself is allowed to free it afterwards. The application does only seem to have rights to read the memory.
If I also make the free function public in class LibRaw it seems to work, but there should be a more elegant solution ;)
Good evening Dan!
I'm a moderator of Russian CG Forum Arttower.ru. Could you give us the permisson to publish the Russian translation of this article (http://www.libraw.su/articles/raw-module.html) on our site?
As for profiles. There is not a profile as such. You need to determine your own cameras RGB to XYZ response. If you have a D70s I could send you some matrixes that I made earlier. I am in the process of publishing a paper on the subject. Ill keep you posted.
I successfully applied CIECAM02 to a RAW imaging workflow. The main problem was to identify the adopted white from scene colorimerty as an input to CIECAM02. I ended up using the cameras white balance for ease in order to complete the experiment. The scene illumination was calculated from ISO and Exposure and gave favorable results. The main part of the process was to characterise the camera using a double monochromator and calculate the cameras spectral response. This was then used to determine the device RGB to XYZ matrix by reducing errors in JMH space for different values of La and white point.
The resulting matrices were used to transform RAW RGB to XYZ according to scene white and La and then passed through CIECAM02.
The internal coordinates used were JMH and output to standard sRGB viewing conditions through the reverse CIECAM02.
I got some pretty good results, (although maybe not appearance perfect) compared to the sRGB JPEG produced by the Nikon D70s.
The problem is in MacOS X fseek() call. It takes 32-bit offset (long int). There is fseeko() function which takes off_t offset and so will work with files larger than 2Gb.
The quick fix:
in libraw/libraw_datastream.h change:
return substream?substream->seek(o,whence):fseek(f,o,whence);
to
return substream?substream->seek(o,whence):fseeko(f,o,whence);
This will break compatibility with Windows (no fseeko) and, possible, Linux. I'll prepare more universal solution (with #ifdef) today or tomorrow (to appear in 0.8-Beta5)
1. Frame offset is stored as 64 bit in this format, so there is no *theoretical* problems.
2. There is two possible sources of problems under Mac OS X:
a) one possible source is 32-bit off_t type (i.e. some special compilation flags are needed because 64-bit offsets are possible)
b) FILE * interface under Mac OS X does not support large files.
I've MacBook with MacOS 10.5 on hands, so will continue investigations. Hope, I'll find problem source today.
Hi, many apologies for the long delay, I got food poisoning after the last post,
and I've been trying to catch up ever since.
I've put a test file on http://www.modern-industry.com/test.cine Its about 49MB.
It is the same case with the brightness contrast: for the majority of street scenes, there is an empirical desire to increase the brightness. This effect was measured by Stevens and Stevens 45 years ago, and the results can be quantitatively used. The reason why you need to increase the contrast of the printouts is the same: you look at them at a much dimmer and duller light than the one that was present during the shooting and presumed by the viewer.
I'm afraid it may not be very easy to repeat, as the file I'm using
is a .cine file of around 16G! I know this sounds an extreme case, but
some professional movie cameras shoot raw...
I didn't use any special switches, just something of the form of
dcraw_emu -s 700 mytestfile.cine
I'm afraid that I'm going to be very busy for the next couple of days, but
a good experiment I might perform would be to create a file with very small frames, so I
can find out if the frame count or the file size is the issue. That might
also create a test case that can be loaded via the Internet.
Link to Rawnalyze backup copy: http://rawnalyze.rawtherapee.com/
Thanks for your patch.
It is integrated into LibRaw 0.11.3 and into coming LibRaw 0.12
You can integrate C-code in MATLAB using the mex-API. I looked at this for dcraw, but got stuck, and I found that it was simply less work to make a thin MATLAB wrapper calling dcraw from the command-line.
I remember some frustrating aspects of doing anything to the dcraw code, hope that this project makes it easier.
(the spam-filter here really hurts!)
Yes, output is converted to 8-bit only on file/memory writing stage (i.e. on output).
So, you may call dcraw_make_mem_image() to create 3-component 8-bit bitmap.
LibRaw (and, so, dcraw_emu) contains 'auto-maximum' feature to deal with 'pink clouds' problem.
If you want to produce files which are binary identical to dcraw's results, you should switch this option off. Use -c 0 switch of dcraw_emu to do that.
New versions of LibRaw are imported in KDE (libkdcraw) very fast. Usually in 1-2 days. So you just need to update your KDE extra libs from KDE trunk
The only real and easy solution is to write your files in .DNG format. Sure, there is no way to write CR2
Please see:
http://www.barrypearson.co.uk/articles/dng/specification.htm#areas
Using dng_validate or an EXIF metadata viewer should be able to tell you the resolutions of the various areas in your DNG file.
The libraw_memmgr::free() is very simple, it just calls upper level ::free than forgets the pointer:
void free(void *ptr) { ::free(ptr); forget_ptr(ptr); }So, if your code crashes in ::free(), it should crash in LibRaw's free() too. For pointer allocated by ::malloc() there is no difference between LibRaw::free() and ::free().
I cannot reproduce this problem in my Windows enviroment (VS2008 SP1, Win7/x64).
Could you please describe your enviroment in more detail (VS2008 patch level, Windows version, may be sample code)?
P.S. Sorry for very aggressive captcha. This is the only way to prevent forum/comments spam.
Please note, that registered/authorized users are not terrorized by captcha :)
I also encounter this problem.
In my project I link the libraw (I use Visual Studio). Everything works fine.
However if I want to free (using ::free(ptr)) the pointer returned by dcraw_make_mem_image(...) I get an exception
_CrtIsValiHeapPointer(pUserData) documented in dbgheap.c with
/*
* If this ASSERT fails, a bad pointer has been passed in. It may be
* totally bogus, or it may have been allocated from another heap.
* The pointer MUST come from the 'local' heap.
*/
_ASSERTE(_CrtIsValidHeapPointer(pUserData));
I think the problem is caused that the lib is creating the memory, so only the lib itself is allowed to free it afterwards. The application does only seem to have rights to read the memory.
If I also make the free function public in class LibRaw it seems to work, but there should be a more elegant solution ;)
Regards Tobias
Since LibRaw 0.9, the OpenMP pragmas are effective only on LibRaw compile time, not at apps compilation.
the image is allocated by 'upper level' (system) malloc, not LibRaw's one:
libraw_processed_image_t *ret = (libraw_processed_image_t*)::malloc(sizeof(libraw_processed_image_t)+ds);
So, it should be free-ed by system free(), not LibRaw::free();
Please describe your enviroment in more details.
Good evening Dan!
I'm a moderator of Russian CG Forum Arttower.ru. Could you give us the permisson to publish the Russian translation of this article (http://www.libraw.su/articles/raw-module.html) on our site?
LibRaw need to seek to arbitrary position in input stream. So, there is no way to read from stdin.
You may implement you own LibRaw_datastreeam class with full buffering.
http://www.digitalcolour.org/toolbox.htm
Dr Green has matlab code for CIECAM02.
As for profiles. There is not a profile as such. You need to determine your own cameras RGB to XYZ response. If you have a D70s I could send you some matrixes that I made earlier. I am in the process of publishing a paper on the subject. Ill keep you posted.
Looks very promising.
Is there some code (plus profile) to play with?
Hi
I successfully applied CIECAM02 to a RAW imaging workflow. The main problem was to identify the adopted white from scene colorimerty as an input to CIECAM02. I ended up using the cameras white balance for ease in order to complete the experiment. The scene illumination was calculated from ISO and Exposure and gave favorable results. The main part of the process was to characterise the camera using a double monochromator and calculate the cameras spectral response. This was then used to determine the device RGB to XYZ matrix by reducing errors in JMH space for different values of La and white point.
The resulting matrices were used to transform RAW RGB to XYZ according to scene white and La and then passed through CIECAM02.
The internal coordinates used were JMH and output to standard sRGB viewing conditions through the reverse CIECAM02.
I got some pretty good results, (although maybe not appearance perfect) compared to the sRGB JPEG produced by the Nikon D70s.
DCRAW and Matlab used for computation.
The problem is in MacOS X fseek() call. It takes 32-bit offset (long int). There is fseeko() function which takes off_t offset and so will work with files larger than 2Gb.
The quick fix:
in libraw/libraw_datastream.h change:
return substream?substream->seek(o,whence):fseek(f,o,whence);
to
return substream?substream->seek(o,whence):fseeko(f,o,whence);
This will break compatibility with Windows (no fseeko) and, possible, Linux. I'll prepare more universal solution (with #ifdef) today or tomorrow (to appear in 0.8-Beta5)
There is two news, good one and not-so-good :)
1. Frame offset is stored as 64 bit in this format, so there is no *theoretical* problems.
2. There is two possible sources of problems under Mac OS X:
a) one possible source is 32-bit off_t type (i.e. some special compilation flags are needed because 64-bit offsets are possible)
b) FILE * interface under Mac OS X does not support large files.
I've MacBook with MacOS 10.5 on hands, so will continue investigations. Hope, I'll find problem source today.
Oh, sorry.
I've downloaded this file several weeks ago, than make LibRaw 0.8-b4, than forgot about file.
Will work with it tomorrow.
gentle ping....
M
Hi, many apologies for the long delay, I got food poisoning after the last post,
and I've been trying to catch up ever since.
I've put a test file on http://www.modern-industry.com/test.cine Its about 49MB.
Mike
It is the same case with the brightness contrast: for the majority of street scenes, there is an empirical desire to increase the brightness. This effect was measured by Stevens and Stevens 45 years ago, and the results can be quantitatively used. The reason why you need to increase the contrast of the printouts is the same: you look at them at a much dimmer and duller light than the one that was present during the shooting and presumed by the viewer.
Sorry, link to warez site deleted by LibRaw admin
You say '16Gb' ?
For many file types data_offset of frame data is read as 32-bit integer (via get4()). So, maximum frame offset is 2Gb.
To check this I need some sample with several frames. I don't need full 16-Gb file multi-multi-frame file, but file with 3-4 frames will be enough.
I'm afraid it may not be very easy to repeat, as the file I'm using
is a .cine file of around 16G! I know this sounds an extreme case, but
some professional movie cameras shoot raw...
I didn't use any special switches, just something of the form of
dcraw_emu -s 700 mytestfile.cine
I'm afraid that I'm going to be very busy for the next couple of days, but
a good experiment I might perform would be to create a file with very small frames, so I
can find out if the frame count or the file size is the issue. That might
also create a test case that can be loaded via the Internet.
Mike
Pages