Hey Alex, Saw the recent release just came out but no CR3 :(. I know it's a difficult problem just wondering what the status is? If you do have a working decoder do you know at this time if it will be made public? And if so do you know a rough date that this may happen? Not trying to be pushy just genuinely curious about the schedule. Thanks again for all the work the team does. Cheers!
We do not do full release cycle for snapshots (only for releases), this is source-code only
Public snapshot source code could be obtained from GitHub: https://github.com/LibRaw/LibRaw/ (master branch)
To compile with MS Visual Studio use nmake -f Makefile.msvc
Assuming modern camera with embedded JPEG preview:
- unpack_thumb() does nothing with rotation, JPEG data are extracted AS is
- (for most cameras) extracted JPEG is either already rotated or contains correct EXIF.Orientation tag.
* dcraw_emu: it is now possible to create output filename in a more flexible manner, via -Z switch:
-Z - will output to stdout
-Z ext will output into inputfilename.ext
-Z .ext will output into inputfilename.inputext.ext
To match vendor (out-of camera JPEG) colors one needs to use same (vendor) color profile data and same contrast (tonal) curve. Tonal curve, in turn, is settings-specific.
Depending on the offset of the active zone, camera model (obviously), and firmware - useful Bayer patterns can be different. Answering pattern questions, specific to model, firmware, or active zone, makes sense only if there is a bug in the library, and only with a "thank you!".
From LibRaw docs:
unsigned black;
Black level. Depending on the camera, it may be zero (this means that black has been subtracted at the unpacking stage or by the camera itself), calculated at the unpacking stage, read from the RAW file, or hardcoded.
my comment: if only one black level value is found / hardcoded / calculated, it is in this field. Before using it, you may want to check the content of cblack.
More from docs:
unsigned cblack[4102];
Per-channel black level correction. First 4 values are per-channel correction, next two are black level pattern block size, than cblack[4]*cblack[5] correction values (for indexes [6....6+cblack[4]*cblack[5]).
my comment: if 4 (per channel) black level values are found / calculated from sources other than Adobe EXIF tag (with one exception that is irrelevant for the matter at hand), for the camera you are interested in they are read into cblack[0 .. 3] in 0 1 3 2 index order (see code, permutations
FORC4 cblack[c ^ c >> 1] = get2();
do that. That's the way Mr. Coffin did it in dcraw, and we preserved it in LibRaw for compatibility.)
if cblack[0] is 0, and / or cblack[4 .. 5] are present (DNG), you can use cblack [6 .. ...]. You can follow the code under "case 0xc61a" to see the order cblack is populated in this case. For a regular DNG, the cycle in essence is
FORC(cblack[4] * cblack[5]) cblack[6+c] = getreal(type);
meaning, the order coming from Adobe EXIF tag is preserved. Again, preserved from dcraw for compatibility.
The CFA for the K5 is BGGR format (silly me for assuming RGGB). So I think the coefficients in cblack[6-9] are in that order. Is the order for cblack[0-3] RGGB - if so that explains the reversal I see - or am I still confused??
I believe that it tells me the order in the DNG file is RGGB (if I read it right) and this this maps directly into cblack[6-9]. It doesn't confirm the order for cblack[0-3] In fact I'm not even sure now about that order given what I see in the cblack array before and after calling adjust_bl() as per my post on 24 June, 2019 - 15:39 which I repeat the data of here:
(edited to remove flame - ib)
yes I did look at the code, but you could have maybe said something like:
Yes the order is different (or not), as you will see if you compare the processing for DNG black level at case xxxxx and the one for Black Point at case yyyyy
And then pointed me at the DNG spec to add more information. I still don't know for certain that cblack[0-3] is in a different order to cblack[6-9]
Thanks for the quick reply, sorry for the misunderstanding. Looking forward to the next release :).
There is no 'recent release', just urgent bugfixes.
We plan to release new snapshot w/ new decoders this Fall
Hey Alex, Saw the recent release just came out but no CR3 :(. I know it's a difficult problem just wondering what the status is? If you do have a working decoder do you know at this time if it will be made public? And if so do you know a rough date that this may happen? Not trying to be pushy just genuinely curious about the schedule. Thanks again for all the work the team does. Cheers!
We do not do full release cycle for snapshots (only for releases), this is source-code only
Public snapshot source code could be obtained from GitHub: https://github.com/LibRaw/LibRaw/ (master branch)
To compile with MS Visual Studio use nmake -f Makefile.msvc
I'm running the latest binary build 0.19.2 but the -Z appears not to be implimented.
Is the 201812 snapshot newer/different branh? If so, where can I get the Win64 binaries?
Thanks in advance!
X-T3 is fully supported in current public snapshot.
Would you like some raw files from an X-T3?
imgdata.sizes.flip is related to raw data only.
Assuming modern camera with embedded JPEG preview:
- unpack_thumb() does nothing with rotation, JPEG data are extracted AS is
- (for most cameras) extracted JPEG is either already rotated or contains correct EXIF.Orientation tag.
There is no Fuji X-T3 in this version supported camera list: https://github.com/LibRaw/LibRaw/blob/3a5280c6d69458a21bd9756d2ee3284738...
19.2
Cheers
thanks (I've looked up into library tarballs, not on site)
https://www.libraw.org/docs#copyright
last date on there is 2016 ...
Since 201812 snapshot:
* dcraw_emu: it is now possible to create output filename in a more flexible manner, via -Z switch:
-Z - will output to stdout
-Z ext will output into inputfilename.ext
-Z .ext will output into inputfilename.inputext.ext
Followup:
black border: X-T3 is supported since 201812 snapshot, what exact LibRaw version do you use?
It operates on raw data populated into image[]
raw_image[] is always untouched (to allow processing of same data multiple times w/o calling unpack())
There are several interpolation options for X-Trans (from fastest to slowest):
- half
- bilinear
- single pass Markesteijn
- 3-pass Markesteijn
Sorry, there is no such function in LibRaw.
To match vendor (out-of camera JPEG) colors one needs to use same (vendor) color profile data and same contrast (tonal) curve. Tonal curve, in turn, is settings-specific.
In what file?
Could you please provide file for analysis (Dropbox/Google Drive/etc link...)
LibRaw uses OpenMP for postprocessing (there is single exception: Fuji compressed decompression is also OpenMP-capable).
AFAIK, you do own postprocessing. So, for most files (see exception above) enabling OpenMP for LibRaw will change nothing.
If your code is OpenMP-enabled, it is up to you what settings to use.
Depending on the offset of the active zone, camera model (obviously), and firmware - useful Bayer patterns can be different. Answering pattern questions, specific to model, firmware, or active zone, makes sense only if there is a bug in the library, and only with a "thank you!".
From LibRaw docs:
unsigned black;
Black level. Depending on the camera, it may be zero (this means that black has been subtracted at the unpacking stage or by the camera itself), calculated at the unpacking stage, read from the RAW file, or hardcoded.
my comment: if only one black level value is found / hardcoded / calculated, it is in this field. Before using it, you may want to check the content of cblack.
More from docs:
unsigned cblack[4102];
Per-channel black level correction. First 4 values are per-channel correction, next two are black level pattern block size, than cblack[4]*cblack[5] correction values (for indexes [6....6+cblack[4]*cblack[5]).
my comment: if 4 (per channel) black level values are found / calculated from sources other than Adobe EXIF tag (with one exception that is irrelevant for the matter at hand), for the camera you are interested in they are read into cblack[0 .. 3] in 0 1 3 2 index order (see code, permutations
FORC4 cblack[c ^ c >> 1] = get2();
do that. That's the way Mr. Coffin did it in dcraw, and we preserved it in LibRaw for compatibility.)
if cblack[0] is 0, and / or cblack[4 .. 5] are present (DNG), you can use cblack [6 .. ...]. You can follow the code under "case 0xc61a" to see the order cblack is populated in this case. For a regular DNG, the cycle in essence is
FORC(cblack[4] * cblack[5]) cblack[6+c] = getreal(type);
meaning, the order coming from Adobe EXIF tag is preserved. Again, preserved from dcraw for compatibility.
Thank you
The CFA for the K5 is BGGR format (silly me for assuming RGGB). So I think the coefficients in cblack[6-9] are in that order. Is the order for cblack[0-3] RGGB - if so that explains the reversal I see - or am I still confused??
I believe that it tells me the order in the DNG file is RGGB (if I read it right) and this this maps directly into cblack[6-9]. It doesn't confirm the order for cblack[0-3] In fact I'm not even sure now about that order given what I see in the cblack array before and after calling adjust_bl() as per my post on 24 June, 2019 - 15:39 which I repeat the data of here:
should I expect the order of cblack[0]-cblack[3] to be the reverse of cblack[6]-cblack[9]???
If I'm not understanding what's going on here please correct my misunderstandings
David
(edited to remove flame - ib)
yes I did look at the code, but you could have maybe said something like:
Yes the order is different (or not), as you will see if you compare the processing for DNG black level at case xxxxx and the one for Black Point at case yyyyy
And then pointed me at the DNG spec to add more information. I still don't know for certain that cblack[0-3] is in a different order to cblack[6-9]
Pages