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.
Yes, for '99%' of cameras (bayer pattern ones) half_size is lossless. For most RGB-bayer patterns there is four different pixel positions in 2x2 block, so if you want to recover exact pixel position you need to examine "filter" field which describes exact layout.
There is some 'special cases': CMYG cameras, Leaf cameras with 8x2 blocks, but most cases are simple.
Also, we'll sometimes refactor this place in LibRaw. Having multiple planes will make simpler to deal with multi-planes cameras: Fuji SuperCCD (2 images in one file), Sinar 4-shot and 16-shot.....
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
identifysample 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
unfortunately, file not found....
wget http://www.jellofishi.com/apps/libraw/mingw/Makefile
--2009-03-01 17:29:09-- http://www.jellofishi.com/apps/libraw/mingw/Makefile
Resolving www.jellofishi.com... 67.15.172.4
Connecting to www.jellofishi.com|67.15.172.4|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2009-03-01 17:29:10 ERROR 404: Not Found.
http://www.jellofishi.com/apps/libraw/mingw/Makefile
Yes, for '99%' of cameras (bayer pattern ones) half_size is lossless. For most RGB-bayer patterns there is four different pixel positions in 2x2 block, so if you want to recover exact pixel position you need to examine "filter" field which describes exact layout.
There is some 'special cases': CMYG cameras, Leaf cameras with 8x2 blocks, but most cases are simple.
Also, we'll sometimes refactor this place in LibRaw. Having multiple planes will make simpler to deal with multi-planes cameras: Fuji SuperCCD (2 images in one file), Sinar 4-shot and 16-shot.....
Sometimes on LibRaw 0.9
Pages