I guess the question I *should* ask is when is the approximate release date for the next version?
I know from experience designing and managing IC design projects you may not be able to give me even an approximate date for a variety of reasons. But if you can, I'd appreciate knowing. Thank you.
I do not know what exactly you want to achieve (-d option behavior in dcraw has changed several times), but yes, no_interpolation = 1 will turn off interpolation and fbdd demoising step(s).
LibRaw's main goal is to extract raw data and metadata from RAW files, we're focused on it.
Postprocessing code (demosaic, etc) is derived from Dave Coffin's dcraw.c and we do not have any plans to improve it in LibRaw. We consider this postprocessing code as 'demo', or as 'quick and far-from-perfect way to implement some processing in other software'.
So, if you want to do something special, e.g. floating point processing, or better negative values handling, or something else, LibRaw provides full access to unaltered pixel values decoded from RAW. Sure, you'll need to implement demosaic and other postprocessing in your software.
ACES matrix is defined in void CLASS convert_to_rgb()
The resulting profile is automatically embedded in the output file if you use -o 6 Your bitmap image processing needs either to acknowledge the embedded profiles, or you can extract the profile from the output and assign it manually. The first solution is the right one.
There is no colour matrix embedded in CR2 files that we know of, and I doubt it is even there. Canon DPP software contains the profiles (mostly they are LUTs, not simple matrices).
Not sure how the compatibility works, but I own a Sony A7 III and a Canon EOS R. If I can scrape any data to help add each of those to the support list, I'd be glad to try.
The only way to get the accurate number for that is to look it up in the sensor data sheet. Raw file may contain virtual pixels, and may not contain all the physical pixels.
It would appear there's a possible bug with libraw in this area.
If I run dcraw -d M103_L_0048_ISO800_60s__16C.CR2, it creates a PGM output file:
29/05/2019 12:01 18,024,947 M103_L_0048_ISO800_60s__16C.pgm
if I run dcraw_emu -disinterp M103_L_0048_ISO800_60s__16C.CR2, it creates a PPM output file:
29/05/2019 12:02 54,074,807 M103_L_0048_ISO800_60s__16C.CR2.ppm
I see two problems:
1) This is the trivial issue that the output fileid is slightly different (which I'm happy to forgive).
2) The major problem is that the output file is NOT a single colour PGM greyscale bitmap as was produced by dcraw, but a 3 colour PPM bitmap.
Cheers
https://www.libraw.org/node/2467
I guess the question I *should* ask is when is the approximate release date for the next version?
I know from experience designing and managing IC design projects you may not be able to give me even an approximate date for a variety of reasons. But if you can, I'd appreciate knowing. Thank you.
We publish releases each 1-1.5 years. We publish snapshots every 5-7 months or so.
Most likely, this link will help: https://www.libraw.org/docs/API-CXX.html#memwrite
I do not know what exactly you want to achieve (-d option behavior in dcraw has changed several times), but yes, no_interpolation = 1 will turn off interpolation and fbdd demoising step(s).
Dear Sir:
LibRaw's main goal is to extract raw data and metadata from RAW files, we're focused on it.
Postprocessing code (demosaic, etc) is derived from Dave Coffin's dcraw.c and we do not have any plans to improve it in LibRaw. We consider this postprocessing code as 'demo', or as 'quick and far-from-perfect way to implement some processing in other software'.
So, if you want to do something special, e.g. floating point processing, or better negative values handling, or something else, LibRaw provides full access to unaltered pixel values decoded from RAW. Sure, you'll need to implement demosaic and other postprocessing in your software.
There is no Java interface in (official) LibRaw.
it should be easy to create using LibRaw C API
ACES matrix is defined in void CLASS convert_to_rgb()
The resulting profile is automatically embedded in the output file if you use -o 6 Your bitmap image processing needs either to acknowledge the embedded profiles, or you can extract the profile from the output and assign it manually. The first solution is the right one.
There is no colour matrix embedded in CR2 files that we know of, and I doubt it is even there. Canon DPP software contains the profiles (mostly they are LUTs, not simple matrices).
I see. I think I did not compile it with USE_JPEG. Thanks!
Just checked with master branch from Github: I do not see any problems with file you provided.
Note: the file is compressed with lossy (JPEG) compression, one need to build LibRaw with USE_JPEG compile-time define to support this kind of DNGs
RAW files from (most/many) cameras contains 'black mask', visible image are is less than full raw data (sensor area)
LibRaw is targeted to general purpose/mass market photographic cameras (see the list above), not special application ones.
However, it will decode any standard photographic raw file, so if some multispectral camera records DNG files, LibRaw will able to read it.
But, have you already sampled on other multispectral cameras?
Most likely no.
We do not have raw files samples from this camera.
Hi! Does this library support multi-spectral cameras such as the Mapir Survey 3?
LibRaw::open_bayer() designed exactly for this
Look into samples/openbayer_sample.cpp for details.
Current public snapshot supports Nikon Z6 and Z7, sorry these cameras was missed from release announce
https://www.libraw.org/news/libraw-snapshot-201903
When the Nikon z6 z7 release the firmware？
Sony A7-3 is supported in current snapshot: https://www.libraw.org/news/libraw-snapshot-201903
EOS-R support is expected in next snapshot/release, whatever comes first.
Not sure how the compatibility works, but I own a Sony A7 III and a Canon EOS R. If I can scrape any data to help add each of those to the support list, I'd be glad to try.
Mhhh ok.
So I will keep my estimation using sizes.width I guess.
The only way to get the accurate number for that is to look it up in the sensor data sheet. Raw file may contain virtual pixels, and may not contain all the physical pixels.
In astrophotography, Pixel size is a value often needed ;).
I don't see any practical sense in getting the exact pixel pitch value. Any approximated value is good enough
Pages