Yes, 0.15 and 0.16 (or 0.11 and 0.12) are binary incompatible due to internals change.
You can use 0.15.x (from 0.15.0 to 0.15.4) or 0.14.x (from 0.14.0 to 0.14.8) without recompile of your app.
But if you change 'major' (second, because first entry is always 0) version, you need to recompile your application.
You may create some wrapper (with getters/setters to access imgdata.* fields) to stabilize the API for your needs (if you need to set only output_bps, you need only one setter call).
OK maybe I'm overlooking something obvious, and correct me if I'm wrong.... but if I re-compile my app each time, and re-compile the libs, then I can link to either the 0.15.4 or 0.16.0 libs? So this is what I have been doing each time that I test. I am aware that the API has changed between those two libs, but I do not know of any functions I'm calling directly from my code that need to be altered to use the two different libs (see code snippet in my previous post).
So my code base stays the same for either lib, yet I get different answers for the bit depth of the same image (after calling dcraw_make_mem_image()) depending on which lib I link to under Mac. Also the windows compile of my app gives the same bit depth for both libs. As I say, maybe I'm overlooking something obvious....
Sorry I should have mentioned that I recompiled my app when linking to the 0.16.0 libs. However, after debugging further I have realised that the LibRaw lib functions actually appear to be working ok, and that my problem lies somewhere else. The problem now is that the 0.15.4 and 0.16.0 libs produce different results for the following code snippet:
For the *same* image, linking to 0.15.4 libs gives bitDepth=16, whereas linking to 0.16.0 libs gives bitDepth=8. This is despite the output_bps parameter being set to 16.
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)
Yes, 0.15 and 0.16 (or 0.11 and 0.12) are binary incompatible due to internals change.
You can use 0.15.x (from 0.15.0 to 0.15.4) or 0.14.x (from 0.14.0 to 0.14.8) without recompile of your app.
But if you change 'major' (second, because first entry is always 0) version, you need to recompile your application.
You may create some wrapper (with getters/setters to access imgdata.* fields) to stabilize the API for your needs (if you need to set only output_bps, you need only one setter call).
Hi Alex, I appreciate the quick response.
OK maybe I'm overlooking something obvious, and correct me if I'm wrong.... but if I re-compile my app each time, and re-compile the libs, then I can link to either the 0.15.4 or 0.16.0 libs? So this is what I have been doing each time that I test. I am aware that the API has changed between those two libs, but I do not know of any functions I'm calling directly from my code that need to be altered to use the two different libs (see code snippet in my previous post).
So my code base stays the same for either lib, yet I get different answers for the bit depth of the same image (after calling dcraw_make_mem_image()) depending on which lib I link to under Mac. Also the windows compile of my app gives the same bit depth for both libs. As I say, maybe I'm overlooking something obvious....
Thanks,
duxy
You cannot replace Libraw 0.15 binary (.so/.dylib) file with 0.16 (and vice versa).
The internal data structures are different.
Hi Alex, thanks for the quick response.
Sorry I should have mentioned that I recompiled my app when linking to the 0.16.0 libs. However, after debugging further I have realised that the LibRaw lib functions actually appear to be working ok, and that my problem lies somewhere else. The problem now is that the 0.15.4 and 0.16.0 libs produce different results for the following code snippet:
For the *same* image, linking to 0.15.4 libs gives bitDepth=16, whereas linking to 0.16.0 libs gives bitDepth=8. This is despite the output_bps parameter being set to 16.
Any insight as to why this would be the case?
Thanks,
duxy
The current development branch (0.17-pre-pre-alpha) has been pushed to GitHub. https://github.com/LibRaw/LibRaw
The A7/A7R cameras are supported
Нет, я не согласен, что так надо делать
Тестовый комментарий
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.
Pages