You ca even use existing tools instead of coding w/ libraw or libtiff, see e.g. http://netpbm.sourceforge.net/doc/rawtopgm.html (and then easily convert PGM to TIFF w/ pamtotiff), or you can also use ImageMagick/GraphicsMagick and define the 'gray' input:
convert -size 512x512 -depth 16 -endian LSB gray:original.bayer -type grayscale result.tif (of course change the dimensions and endianness to suit your need)
Dear Sir:
We do support all raw samples from Leaf Aptus 17 that we have.
The easiest way to check if your files are supported is to download free trial of FastRawViewer https://www.fastrawviewer.com/download and open your .mos files with it.
I can't browse mos file on my windows 10 PC.
It is installed raw image extension program.But it doesn't work.
Mos file have been shot by leaf aptus 17.
That problem is viewing dark image preview on my PC.
I hope you support leaf aptus 17 raw file format.
I am trying to recreate the pixel statistics (min/max/avg/σ) that appear in RawDigger (per channel). Am I correct in assuming you are the authors of this software? If yes, then which LibRaw parameter was used to obtain these values?
Thanks
Well, I was originally trying to perform my analysis on difference images (subtract one image with identical parameters from another in order to remove flat field effects) but I'm getting ridiculously large values for the std dev (in the 1000s) which doesn't seem right. Am I being naive in assuming I can simply subtract the values of one raw array from the other?
DNG format is TIFF format + some additional tags.
So your options are:
- Adobe DNG SDK
- libtiff (you'll need to add tags using libtiff calls)
- plain write w/o addional libraries.
In this specific case LibRaw/dcraw_emu works better (more correctly) than dcraw.
This is especially true for DNG files with multiple sub-images and different color data (e.g. DNG w/ fast-load JPEG data): LibRaw/dcraw will select correct matrix, while dcraw will always use the last one.
dcraw parses DNG tags one-by-one, in order (in file being processed), both ColorMatrix1 and ColorMatrix2 tags are parsed into same (cmatrix) structure. So, latest one wins.
LibRaw w/ default settings (without LIBRAW_PROCESSING_DONT_CHECK_DNG_ILLUMINANT flag) analyzes CalibrationIlluminant1/2 tags too and selects color matrix which is closer to D65/daylight.
Usually (e.g. files created by Adobe DNG SDK) the last matrix is the one that corresponds to daylight (resulting in same dcraw/dcraw_emu results), but not in this specific file (CameraMatrix1 => D65, CameraMatrix2 => Ill.A).
So, LibRaw is right in this specific case, while dcraw is not.
(dcraw is *much* worse if DNG file contains multiple sub-images w/ different color data).
You ca even use existing tools instead of coding w/ libraw or libtiff, see e.g. http://netpbm.sourceforge.net/doc/rawtopgm.html (and then easily convert PGM to TIFF w/ pamtotiff), or you can also use ImageMagick/GraphicsMagick and define the 'gray' input:
convert -size 512x512 -depth 16 -endian LSB gray:original.bayer -type grayscale result.tif (of course change the dimensions and endianness to suit your need)
why don't you want to use libtiff?
You already have sensor dump in memory array, unprocessed. Just write it to file, you do not need to use LibRaw::open_bayer() for that.
Dear Sir:
We do support all raw samples from Leaf Aptus 17 that we have.
The easiest way to check if your files are supported is to download free trial of FastRawViewer https://www.fastrawviewer.com/download and open your .mos files with it.
I can't browse mos file on my windows 10 PC.
It is installed raw image extension program.But it doesn't work.
Mos file have been shot by leaf aptus 17.
That problem is viewing dark image preview on my PC.
I hope you support leaf aptus 17 raw file format.
As soon as we consider that everything is ready
Any projected date for the final release yet?
Thank you Lexa! I appreciate the pointers.
samples/unprocessed_raw.cpp sample is also a good starting point if you need unaltered raw values.
Quote from above:
> You can use 4channels sample to split source RAW into four separate TIFF files.
(or you can use 4channels sample source as reference for your code)
OK, but it's not possible to get the R/G/B/G2 values without postprocessing, or am I confused?
RawDigger calculated statistics on unaltered RAW values, the only processing performed is black level subtraction (if not turned off by user).
I am trying to recreate the pixel statistics (min/max/avg/σ) that appear in RawDigger (per channel). Am I correct in assuming you are the authors of this software? If yes, then which LibRaw parameter was used to obtain these values?
Thanks
Well, I was originally trying to perform my analysis on difference images (subtract one image with identical parameters from another in order to remove flat field effects) but I'm getting ridiculously large values for the std dev (in the 1000s) which doesn't seem right. Am I being naive in assuming I can simply subtract the values of one raw array from the other?
To add to what Alex just said, what demosaic, when what you want is sensor PTCs?
You can use 4channels sample to split source RAW into four separate TIFF files.
Yes but... if I just use raw_image I only get a 2D array back.
If I need colour channels I need to manually demosaic?
You do not need postprocessing step(s) if you want to analyze unaltered raw data
Some examples of `light` DNG creation tools:
http://a1ex.magiclantern.fm/bleeding-edge/pgm2dng.c (needs a few more files from CHDK)
https://github.com/fastvideo/pgm2dng
LibRaw only reads files, not writes.
DNG format is TIFF format + some additional tags.
So your options are:
- Adobe DNG SDK
- libtiff (you'll need to add tags using libtiff calls)
- plain write w/o addional libraries.
Thanks a lot Alex !
It work well now !
Lucien
You need this only for Microsoft or Intel compilers. For others LIBRAW_WIN32_DLLDEFS is not defined automatically.
For the static library, you must define LIBRAW_NODLL when compiling programs that link to it.
In this specific case LibRaw/dcraw_emu works better (more correctly) than dcraw.
This is especially true for DNG files with multiple sub-images and different color data (e.g. DNG w/ fast-load JPEG data): LibRaw/dcraw will select correct matrix, while dcraw will always use the last one.
Thanks for your reply!
Yes, I've done a side-by-side debug run of dcraw and LibRaw example, and I've found the divergence point.
Can dcraw_emu be used as a replacement of dcraw, or it is just an example program that is not intended for everyday use?
dcraw parses DNG tags one-by-one, in order (in file being processed), both ColorMatrix1 and ColorMatrix2 tags are parsed into same (cmatrix) structure. So, latest one wins.
LibRaw w/ default settings (without LIBRAW_PROCESSING_DONT_CHECK_DNG_ILLUMINANT flag) analyzes CalibrationIlluminant1/2 tags too and selects color matrix which is closer to D65/daylight.
Usually (e.g. files created by Adobe DNG SDK) the last matrix is the one that corresponds to daylight (resulting in same dcraw/dcraw_emu results), but not in this specific file (CameraMatrix1 => D65, CameraMatrix2 => Ill.A).
So, LibRaw is right in this specific case, while dcraw is not.
(dcraw is *much* worse if DNG file contains multiple sub-images w/ different color data).
Pages