Thanks again, and sorry about the false assumption that dcraw_process() was 8 bits...
I noticed the "only one of rgbg is not null for each pixel" thing... Why is that so?
Could it be that my 16MPixels camera would in fact be a camera with 4M realPixels (16M subPixels, each of them being either r, g or b), and not a 16*4M subPixels camera?
dcraw_process() is 16 bit internally. Processing result is scaled to 8 bit (if asked) on output routines.
raw2image converts from bayer data (flat, 1 value per pixel) to 4-component image[][4]. Only one component of image is non-zero after raw2image. This is NOT demosaiced image, but data prepared for demosaic (this format is back-compatible to old LibRaw versions, that's why raw2image call is provided).
To get color index (index of non-zero element in 4-component pixel) use COLOR(row,col) call.
With default settings, LibRaw processing:
1) Adjust data maximum using real maximum in RAW file (use params.adjust_maximum_thr to adjust)
2) Brighten image to put 1% in saturation (parms.auto_bright_thr to adjust, or turn brightening off via params.no_auto_bright)
Darktable uses own raw processing with all things different.
If you have two PNG converters, that take a BMP and turn it into PNG form and found that the output from these converters were different, what would you do? Note that PNG is simply using lossless compression on a BMP any differences means someone is at fault!
Why does this change for RAW converters? Aren't RAW converters "suppose" to be "lossless" or are they horrifically lossy programs that have been touted about as needed by people who have a vested interest in keeping the status quo?
OpenRAW makes far more sense. Proprietary formats don't matter so much as holding a knife to Adobe's throat and saying "we're documenting our RAWs now, so update your code for all platforms because you only exist because of our customers." Companies working together for the betterment of the consumer rather than whatever they think they're doing, should be the real goal here.
Fuji X-Trans is so special and requires different processing in most cases, so COLOR() really used only in bayer processing code, but not in X-Trans.
BTW, this need to be fixed and COLOR() should return correct color even for X-Trans files too. I'll reply to this thread again after pushing fix to github repo.
Thanks again, and sorry about the false assumption that dcraw_process() was 8 bits...
I noticed the "only one of rgbg is not null for each pixel" thing... Why is that so?
Could it be that my 16MPixels camera would in fact be a camera with 4M realPixels (16M subPixels, each of them being either r, g or b), and not a 16*4M subPixels camera?
dcraw_process() is 16 bit internally. Processing result is scaled to 8 bit (if asked) on output routines.
raw2image converts from bayer data (flat, 1 value per pixel) to 4-component image[][4]. Only one component of image is non-zero after raw2image. This is NOT demosaiced image, but data prepared for demosaic (this format is back-compatible to old LibRaw versions, that's why raw2image call is provided).
To get color index (index of non-zero element in 4-component pixel) use COLOR(row,col) call.
Yes.
To get behaviour very similar to dcraw (including 'pink clouds' problem) set params.adjust_maximum_thr to 0.0f;
To change auto-brigtening use auto_bright_thr or manual brightness adjustment.
Do you say that I can somehow manually change the way LibRaw behaves?
Thanks.
LibRaw 0.17 works fine with these files, so switch to actual release
(I'll not inspect LibRaw 0.16 for this problem, because 0.16 branch will receive only critical security bugfixes).
https://yadi.sk/d/DQkLznQcj9JeT
https://yadi.sk/d/FIj0e9Uhj9JdL
With default settings, LibRaw processing:
1) Adjust data maximum using real maximum in RAW file (use params.adjust_maximum_thr to adjust)
2) Brighten image to put 1% in saturation (parms.auto_bright_thr to adjust, or turn brightening off via params.no_auto_bright)
Darktable uses own raw processing with all things different.
egor@shutter:~/src/libraw/LibRaw-0.16.2/bin$ ./simple_dcraw -v -4 -T ~/tmp/raw/IMGP3859.PEF
Processing file /home/egor/tmp/raw/IMGP3859.PEF
/home/egor/tmp/raw/IMGP3859.PEF: data corrupted at 160143
Cannot unpack /home/egor/tmp/raw/IMGP3859.PEF: Input/output error
egor@shutter:~/src/libraw/LibRaw-0.16.2/bin$ cd ../../LibRaw-0.17.0/bin/
egor@shutter:~/src/libraw/LibRaw-0.17.0/bin$ ./simple_dcraw -v -4 -T ~/tmp/raw/IMGP3859.PEF
Processing file /home/egor/tmp/raw/IMGP3859.PEF
Writing file /home/egor/tmp/raw/IMGP3859.PEF.tiff
egor@shutter:~/src/libraw/LibRaw-0.17.0/bin$
Could you please upload sample file somewhere (dropbox, etc) and share the link.
If you have two PNG converters, that take a BMP and turn it into PNG form and found that the output from these converters were different, what would you do? Note that PNG is simply using lossless compression on a BMP any differences means someone is at fault!
Why does this change for RAW converters? Aren't RAW converters "suppose" to be "lossless" or are they horrifically lossy programs that have been touted about as needed by people who have a vested interest in keeping the status quo?
OpenRAW makes far more sense. Proprietary formats don't matter so much as holding a knife to Adobe's throat and saying "we're documenting our RAWs now, so update your code for all platforms because you only exist because of our customers." Companies working together for the betterment of the consumer rather than whatever they think they're doing, should be the real goal here.
Got the file, thanks.
This is very special case:
color.maximum is calculated from metadata for these files, this is just 0xfffc - black_level
And after LibRaw::unpack() real data maximum is within this range.
But on postprocessing stage, PhaseOne data are linearized using other metadata contained in file (complex process in phase_one_flat_field() call).
After that stage, real (linearized) data values may have values above color.maximum
The best way it to share it somewhere (Dropbox, google) and send me link.
Or just send via E-mail
my personal e-mail is lexa@lexa.ru
Sure, how to send you the file (46,9 MB)?
This is possible and normal for some formats. For example, for DNG files color.maximum is read from corresponding tag, that may contain anything.
BTW, could you provide sample file for analysis?
LibRaw do not write RAW data in any format. It can store processing results in .ppm or .tiff, that's all.
Consider Adobe DNG SDK, it can read and write DNG files.
Could you please specify more details
- environment (OS, etc)
- compiler used
- interpolation mode used
Thank you!
You may use fcol() instead of FC() in COLOR() definition:
int COLOR(int row, int col) { return libraw_internal_data.internal_output_params.fuji_width? FCF(row,col):fcol(row,col);}This is not so efficient because fcol() is not inlined, but if you do not use COLOR() for all pixels of image, it will work.
fcol do not take into account Fuji SuperCCD specifics.
What is LibRaw::fcol, can it be used instead?
Fuji X-Trans is so special and requires different processing in most cases, so COLOR() really used only in bayer processing code, but not in X-Trans.
BTW, this need to be fixed and COLOR() should return correct color even for X-Trans files too. I'll reply to this thread again after pushing fix to github repo.
For most (TIFF/EP) raw files, EXIF data is pointed by EXIF (34665) tag
Make and model for these files are parsed in other place.
Can you tell me the method to find the exif metadata location in Raw files?
How about other parameters like "camera model" ,"camera make", like this Exif metadata, how can you read it to the libraw datastructure?
Pages