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.
After much experiment, I tried the same code on an Ubuntu 9.04 box, and it works perfectly. Backporting the same code back to OS X gives me the original problem.
Finally, I just tried dcraw_emu from the samples directory, and that suffers the
same problem, so I've eliminated my application code.
There are 2 items I would like to see enhanced in the current Raw conversion libraries out there:
1. I would like extra output 32-bit float instead of kist 16-bit integer.
2. The ability to quickly extract a section of an image. Lets say I want to create a zoom tool that zooms into a section of a Raw file I would like to have a fast Raw library that only process the pixels involved in the area you are zooming in. I'm aware that raw is a stream of data but at leas a fast way of walking through the stream instead of interpolating all the pixels on its way.
The typical shape of the curve is lighter in the midtone and darker in the three-quartertone. However, it would be easy to incorporate some presets that would permit users to choose the type of color enhancement.
*Decoding* process is very simple and limited to file (disk) bandwidth.
Postprocessing (demosaicing, color conversion, noise suppression etc) is another story. GPU may help a lot. On the other side, only very good quality postprocessing code should be accelerated, there is no need to very fast and very bad postprocessing. We think, that current LibRaw postprocessing implementation is bad enough....
because the #line directives in various files direct to it. Unfortunately downloading dcraw.c doesn't help, because it changes all the time and is therefore out of sync with libraw.
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
Could you please describe how to repeat the problem with dcraw_emu? What command-line switches used?
After much experiment, I tried the same code on an Ubuntu 9.04 box, and it works perfectly. Backporting the same code back to OS X gives me the original problem.
Finally, I just tried dcraw_emu from the samples directory, and that suffers the
same problem, so I've eliminated my application code.
Any further input welcome...
There are 2 items I would like to see enhanced in the current Raw conversion libraries out there:
1. I would like extra output 32-bit float instead of kist 16-bit integer.
2. The ability to quickly extract a section of an image. Lets say I want to create a zoom tool that zooms into a section of a Raw file I would like to have a fast Raw library that only process the pixels involved in the area you are zooming in. I'm aware that raw is a stream of data but at leas a fast way of walking through the stream instead of interpolating all the pixels on its way.
The typical shape of the curve is lighter in the midtone and darker in the three-quartertone. However, it would be easy to incorporate some presets that would permit users to choose the type of color enhancement.
erreauk
Unfortunately, I'm not an Matlab user, so cannot provide significant help.
I guess, Matlab must have some interface to external libraries. LibRaw is a library, you can compile it according to Matlab requirements and use.
Is there an easy way to use LibRAW to move the whole processing procedure into Matlab?
Thanks.
Thank you, much appreciated.
You should call open() on each iteration:
for(x=0; ; x++) {
RawProcessor.open(filename);
if(x>P1.raw_count) break;
RawProcessor.unpack();
process();
}
I should mention that the loop for getting multiple images
looks something like:
for(x=0; x < P1.raw_count; x++) {
OUT.shot_select = x;
RawProcessor.unpack();
RawProcessor.dcraw_process();
}
libopenraw is completely different project.
*Decoding* process is very simple and limited to file (disk) bandwidth.
Postprocessing (demosaicing, color conversion, noise suppression etc) is another story. GPU may help a lot. On the other side, only very good quality postprocessing code should be accelerated, there is no need to very fast and very bad postprocessing. We think, that current LibRaw postprocessing implementation is bad enough....
Thank you for your suggestion.
We'll rename identify sample to libraw_identify
Maybe you could rename the
identify
sample program. Anybody who installs it will have a conflict with ImageMagick's command of the same name.You're right.
We'll include original dcraw.c in next release.
because the #line directives in various files direct to it. Unfortunately downloading dcraw.c doesn't help, because it changes all the time and is therefore out of sync with libraw.
http://www.jellofishi.com/apps/libraw/mingw/Makefile.mingw
Pages