LibRaw *major* versions are not binary compatible (i.e. if you replace 0.15.xx to 0.16.xx you need to recompile your app). This is because internals are changed.
Correct versioning is implemented in configure and cmake scripts (and for Linux). I'm not sure, that configure/cmake scripts works well under Mac.
A7R is supported in (internal) development branch. It is under (heavy) internals change, so I do not push it to github (public repo) on regular schedule.
I can push it once, but this is *development* release, no guarantee for seamless work (and, sure, it is not binary compatible with 0.16).
I'm not Windows development guru, so I'm not sure.
The DLLs are compiled with Microsoft Visual C++ with /LD switch (create DLL). I suspect, these DLLs are Cdecl because made with C/C++ without any additional settings.
Because LibRaw is distributed in open-source, you can easily modify it as you wish, including functions calling conventions.
You're using raw_width/raw_height as image[] array size, so you're run out of array bounds.
The image array is sizes.iwidth * sizes.iheight in size.
More details:
raw image from sensor contains image itself and some 'masked pixels' (or optical black pixels, or 'masked frame') at the image edges..
The full sensor (raw data) size is raw_width x raw_height
The visible area size is sizes.width x sizes.height
The image array size is sizes.iwidth x sizes.iheight ( iwidth == width and iheight == height unless you set params.half_size to non-zero).
So you need to set your rwidth variable to sizes.iwidth (and same for rheight = sizes.iheight).
Hi Alex,
I am using python ctypes to call the c api to libraw. With D5200 and D7100 nef files it works, but with D4, D700, D800 etc it fails. I noted that D700 is actually a smaller image[] array than D7100.
Here is my code: (I did not include the massive struct declarations from the top of the source code for brevity).
from ctypes import *
from ctypes.util import find_library
import numpy as np
from PIL import image
lr=CDLL('libraw')
#read test file into buf
buf=create_string_buffer(open('colortest.nef', 'rb').read())
#make it so init returns a pointer to struct declared above
lr.libraw_init.restype = POINTER(libraw_data_t)
handle = lr.libraw_init(0)
lr.libraw_open_buffer(handle, buf, len(buf))
lr.libraw_unpack(handle)
lr.libraw_raw2image(handle)
rwidth=handle.contents.sizes.raw_width
rheight=handle.contents.sizes.raw_height
size=4*rwidth*rheight*2 #size of image[] , 2 is np.uint16 size
#open handle.contents.image as a numpy array of unsigned 16bit integers
buffer_from_memory = pythonapi.PyBuffer_FromMemory
buffer_from_memory.restype = py_object
buffer = buffer_from_memory(handle.contents.image, size)
a= np.frombuffer(buffer, np.uint16)
#reshape from 1d to 2d array
a.shape=(rwidth*rheight,4)
#grab only the red pixel array and store it in rs
rs = a[:,0].reshape(rheight,rwidth)
#save rs as 16bit tiff
im = Image.fromarray(rs, mode='I;16')
im.save('testred.tif')
So if I run this code with my NEF files, as long as the nef file has d7100 in the exif data, it will save a tiff. If it finds, for example, D800 I will get a seg fault which mentions memcpy() . Because I am using python with ctypes I do not get much more information than that.
I tested several of the included executable in libraw and they all work for all of my nef files.
Sorry I was not very descriptive.
Whenever it fails, I get a segmentation fault when I try to read out the values from the image[] array to save them. When it works my code successfully saves a tiff (which is just a test case- I save only the red pixels- the image[][0] array).
Take look of 4channels sample in LibRaw/samples.
It works very simple
- it uses half-mode to fill all elements of image[] array (but the array is 1/4 of size, so every 4 bayer pixels are folded into one image[][4])
- it demonstrates access to image[][] elements for auto-scale
Here is the really strange thing... if I modify the EXIF data of the d800 nef file and change it to say d7100, it works perfectly (I only need the unpacked image data since I handle post processing in my program). No more seg faults. I have no idea why this is the case.
Also you were right-- the red and blue channels do contain some signal that we want to keep.
Thank you very much for your help! I have been working on this a lot the past few days and have made significant progress. I have a problem though and not sure if you might be able to point me in the right direction.
My code works perfectly with files from D7100 and D5200, but fails on all other .NEF files. I understand Nikon made some changes with d7100 and d5200, but can seem to figure out how this would affect my use of libraw.
The libraw executables alone still work fine with all the nef files I try, but for some reason my code only takes d7100 or d5200 and I have no idea why.
Thanks again.
Edit- more info. My code segfaults when I don't use d7100 or d5200 NEFs.
After these piece of code, your image pixels will reside in lr.imgdata.image[][4] array.
To access pixel value you may use lr.imgdata.image[(row*width)+col][C], where C is color index (R: 0, G: 1, B: 2, Green2: 3).
So, you may interpolate anything you want using only G and G2 channel data.
Use lr.COLOR(row,col) to get color index for given pixel (i.e. which bayer color corresponds to row/col pair)
Alex you got it, I don't get the identity matrix at all!
I then manually inverted the matrix using an online service and saw that pseudoinverse gives a very inaccurate result. If I convert the image using the right values, then the image goes back to rgb properly.
So it is all down to the matrix inversion accuracy..
Thanks for your help!
have you checked that your inverted matrix multiplied to original srgb-to-something matrix produces 'identity matrix' (1s on diagonal and zeroes on all other elements)
Please think of this: the scene you are shooting linear. Monitor gamma is applied for inverse companding of the image that has a high gamma. The resulting image on the monitor after inverse companding is close to linear, just as it is in the real world.
The data values in image[] (and raw_image) array are in linear space
The gamma correction applied only on output (dcraw_make_mem_image(), dcraw_ppm_tiff_writer() calls)
convert_to_rgb() only fills the curve[] with gamma_curve() call and rgb maximum calculated on convert-to-rgb stage.
If you need linear output in dcraw_make_mem_image()/ppm_tiff_writer, set output_params.gamm[0] and [1] to 1.0
Cmake files are contributed to LibRaw by our users. If these files are broken, please submit patch using github pull requests system. LibRaw repo is at https://github.com/LibRaw/LibRaw
LibRaw *major* versions are not binary compatible (i.e. if you replace 0.15.xx to 0.16.xx you need to recompile your app). This is because internals are changed.
Correct versioning is implemented in configure and cmake scripts (and for Linux). I'm not sure, that configure/cmake scripts works well under Mac.
A7R is supported in (internal) development branch. It is under (heavy) internals change, so I do not push it to github (public repo) on regular schedule.
I can push it once, but this is *development* release, no guarantee for seamless work (and, sure, it is not binary compatible with 0.16).
My Digikam 3.5.0 can open Sony A7R RAW files, BUT the colours are strange and images appear as though under frosted glass.
Can you correct and add the A7R camera to your list of supported cameras?
Thank you.
I'm not Windows development guru, so I'm not sure.
The DLLs are compiled with Microsoft Visual C++ with /LD switch (create DLL). I suspect, these DLLs are Cdecl because made with C/C++ without any additional settings.
Because LibRaw is distributed in open-source, you can easily modify it as you wish, including functions calling conventions.
Thank you Alex.
That fixed it instantly! Your help is much appreciated.
you're run out of array bounds. see my previous comment above.
You're using raw_width/raw_height as image[] array size, so you're run out of array bounds.
The image array is sizes.iwidth * sizes.iheight in size.
More details:
raw image from sensor contains image itself and some 'masked pixels' (or optical black pixels, or 'masked frame') at the image edges..
The full sensor (raw data) size is raw_width x raw_height
The visible area size is sizes.width x sizes.height
The image array size is sizes.iwidth x sizes.iheight ( iwidth == width and iheight == height unless you set params.half_size to non-zero).
So you need to set your rwidth variable to sizes.iwidth (and same for rheight = sizes.iheight).
Hi Alex,
I am using python ctypes to call the c api to libraw. With D5200 and D7100 nef files it works, but with D4, D700, D800 etc it fails. I noted that D700 is actually a smaller image[] array than D7100.
Here is my code: (I did not include the massive struct declarations from the top of the source code for brevity).
from ctypes import * from ctypes.util import find_library import numpy as np from PIL import image lr=CDLL('libraw') #read test file into buf buf=create_string_buffer(open('colortest.nef', 'rb').read()) #make it so init returns a pointer to struct declared above lr.libraw_init.restype = POINTER(libraw_data_t) handle = lr.libraw_init(0) lr.libraw_open_buffer(handle, buf, len(buf)) lr.libraw_unpack(handle) lr.libraw_raw2image(handle) rwidth=handle.contents.sizes.raw_width rheight=handle.contents.sizes.raw_height size=4*rwidth*rheight*2 #size of image[] , 2 is np.uint16 size #open handle.contents.image as a numpy array of unsigned 16bit integers buffer_from_memory = pythonapi.PyBuffer_FromMemory buffer_from_memory.restype = py_object buffer = buffer_from_memory(handle.contents.image, size) a= np.frombuffer(buffer, np.uint16) #reshape from 1d to 2d array a.shape=(rwidth*rheight,4) #grab only the red pixel array and store it in rs rs = a[:,0].reshape(rheight,rwidth) #save rs as 16bit tiff im = Image.fromarray(rs, mode='I;16') im.save('testred.tif')So if I run this code with my NEF files, as long as the nef file has d7100 in the exif data, it will save a tiff. If it finds, for example, D800 I will get a seg fault which mentions memcpy() . Because I am using python with ctypes I do not get much more information than that.
I tested several of the included executable in libraw and they all work for all of my nef files.
Sorry I was not very descriptive.
Whenever it fails, I get a segmentation fault when I try to read out the values from the image[] array to save them. When it works my code successfully saves a tiff (which is just a test case- I save only the red pixels- the image[][0] array).
Take look of 4channels sample in LibRaw/samples.
It works very simple
- it uses half-mode to fill all elements of image[] array (but the array is 1/4 of size, so every 4 bayer pixels are folded into one image[][4])
- it demonstrates access to image[][] elements for auto-scale
Segfaults: please show the code. It is possible, that you run out of image[] array bounds.
What do you mean for 'fails' (and 'works properly')?
The data are not in image[] array or what?
Here is the really strange thing... if I modify the EXIF data of the d800 nef file and change it to say d7100, it works perfectly (I only need the unpacked image data since I handle post processing in my program). No more seg faults. I have no idea why this is the case.
Also you were right-- the red and blue channels do contain some signal that we want to keep.
Hi Alex,
Thank you very much for your help! I have been working on this a lot the past few days and have made significant progress. I have a problem though and not sure if you might be able to point me in the right direction.
My code works perfectly with files from D7100 and D5200, but fails on all other .NEF files. I understand Nikon made some changes with d7100 and d5200, but can seem to figure out how this would affect my use of libraw.
The libraw executables alone still work fine with all the nef files I try, but for some reason my code only takes d7100 or d5200 and I have no idea why.
Thanks again.
Edit- more info. My code segfaults when I don't use d7100 or d5200 NEFs.
The red and blue filters on most digital cameras are 'wide', so these channels will respond to your (monochrome green) signal.
BTW, if you want to ignore R/B data completely, you may use:
LibRaw lr; lr.open_file("filename.raw"); lr.unpack(); lr.raw2image();After these piece of code, your image pixels will reside in lr.imgdata.image[][4] array.
To access pixel value you may use lr.imgdata.image[(row*width)+col][C], where C is color index (R: 0, G: 1, B: 2, Green2: 3).
So, you may interpolate anything you want using only G and G2 channel data.
Use lr.COLOR(row,col) to get color index for given pixel (i.e. which bayer color corresponds to row/col pair)
Alex you got it, I don't get the identity matrix at all!
I then manually inverted the matrix using an online service and saw that pseudoinverse gives a very inaccurate result. If I convert the image using the right values, then the image goes back to rgb properly.
So it is all down to the matrix inversion accuracy..
Thanks for your help!
have you checked that your inverted matrix multiplied to original srgb-to-something matrix produces 'identity matrix' (1s on diagonal and zeroes on all other elements)
Ok, I think it is rather clear now. Thanks.
Please think of this: the scene you are shooting linear. Monitor gamma is applied for inverse companding of the image that has a high gamma. The resulting image on the monitor after inverse companding is close to linear, just as it is in the real world.
BTW, if you want to display/analyze/whatever of RAW data, take look of RawDigger program. http://www.rawdigger.com
The data values in image[] (and raw_image) array are in linear space
The gamma correction applied only on output (dcraw_make_mem_image(), dcraw_ppm_tiff_writer() calls)
convert_to_rgb() only fills the curve[] with gamma_curve() call and rgb maximum calculated on convert-to-rgb stage.
If you need linear output in dcraw_make_mem_image()/ppm_tiff_writer, set output_params.gamm[0] and [1] to 1.0
Thank you Alex, I am going to open another topic about gamma correction....
You're right, these comments are very outdated (from very old dcraw source code).
For now, cmatrix and rgb_cam are used to color conversion too.
Cmake files are contributed to LibRaw by our users. If these files are broken, please submit patch using github pull requests system. LibRaw repo is at https://github.com/LibRaw/LibRaw
Raw tone curve is applied on LibRaw::unpack() (data extraction).
You may assume that data values are linear after unpack()
Pages