When calling dcraw_make_mem_image (or even copy_mem_image) the libraw_processed_image_t.data order is [R (0), G (0), B (0), R (1), G (1), B (1)] where (n) is the nth pixel, right? Does this change when the output is 16 bits since a char may only be 8 bits on some platforms? If so, what does the order look like?
I tried mem-image.cpp (from terminal writing to ppm) and it worked, which means it probably is an issue when converting to Java. Byte is signed because all java data types are signed however, when casting to an int you can get the unsigned value by using & 0xFF on the byte. If I do this, or just use an int[] instead of a byte[], I lose the yellow color (new image).
Your image sample is not bayer patten, but something strange (in bayer pattern you'll see image, may be with wrong colors or reduced brigtness, but image subject will be visible).
Most likely, this is signed/unsigned conversion problem, or wrong row stride.
Use samples/mem-image.cpp as an example of dcraw_make_mem_image() call, make sure this example can process your DNG, than modify this code for your needs.
public static Bitmap createFromColorChannels(byte[] channels, int width, int height) {
int[] color = new int[channels.length / 3];
for (int i = 0; i < color.length; i++) {
color[i] = Color.rgb(channels[i], channels[i + 1], channels[i + 2]);
}
...
Also, your patch will read additional byte via f = getc(ifp);
I do not see any attempt to add this byte back to the input stream. Most likely, your code does not decode correct data right.
I have the same need as the OP, so I figured I'd comment rather than make a whole new post. How can I get a debayered RGB bitmap out of a RAW nef file?
EDIT: nevermind, I have an unpublished post with my question in it.
Okay, I'll upload another one soon. However how does LibRaw handle these cases? I mean if the tag is absent and I try to access its contents what is the expected result? Or better yet, is there a good way of checking it?
Yes I understand, but how would I go about running the examples (i.e. 4channels.exe) in Visual Studio after installing the library?
DLL file is a (shared) library, it cannot be 'started'
There is no such things as a 'bit depth':
Imagine Sony ARW2 format (described in details here: http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection ):
- local 7-bit lossy storage
- 11-bit non-linear after lossy (de)compression
- 0..17204 data range after linearization curve (so, 'more than 14bits'
Also, advertized as 14-bit ADC (Sony A7 series), but data gapped even in shadows).
So, what bitdepth?
LibRaw provides data range (maximum value) in imgdata.color.maximum
copy_mem_image() is called from dcraw_make_mem_image() with bgr parameter set to 0.
So, the order is always RGB
When calling dcraw_make_mem_image (or even copy_mem_image) the libraw_processed_image_t.data order is [R (0), G (0), B (0), R (1), G (1), B (1)] where (n) is the nth pixel, right? Does this change when the output is 16 bits since a char may only be 8 bits on some platforms? If so, what does the order look like?
I tried mem-image.cpp (from terminal writing to ppm) and it worked, which means it probably is an issue when converting to Java. Byte is signed because all java data types are signed however, when casting to an int you can get the unsigned value by using & 0xFF on the byte. If I do this, or just use an int[] instead of a byte[], I lose the yellow color (new image).
BTW, is byte type signed or unsigned?
Your image sample is not bayer patten, but something strange (in bayer pattern you'll see image, may be with wrong colors or reduced brigtness, but image subject will be visible).
Most likely, this is signed/unsigned conversion problem, or wrong row stride.
Use samples/mem-image.cpp as an example of dcraw_make_mem_image() call, make sure this example can process your DNG, than modify this code for your needs.
The following code creates 32 bit ARGB:
dcraw_make_mem_image() creates 24-bit RGB, not 32-bit ARGB
Ok.
The FreeImage source code contains the old version without the fix (0.17.a1). I will include only the fix in our code.
Thanks.
Also, your patch will read additional byte via f = getc(ifp);
I do not see any attempt to add this byte back to the input stream. Most likely, your code does not decode correct data right.
Actual LibRaw already contains this check and additional loop count check
No exact timeframe, most likely 'later this year'.
'Release Plan' should be response to user's feature requests, but we do not see these requests.
...and a release plan will be a plus for this project...
Libraw internal pixel format is always 16-bit unsigned integer.
16->8 bit conversion (and gamma correction) is performed on make_mem_image() stage.
Could you please provide raw file sample to check?
Use simple_dcraw.cpp sample as an example code
I have the same need as the OP, so I figured I'd comment rather than make a whole new post. How can I get a debayered RGB bitmap out of a RAW nef file?
EDIT: nevermind, I have an unpublished post with my question in it.
imgdata.other.parsed_gps.gpsparsed is non-zero if gps data has parsed.
Okay, I'll upload another one soon. However how does LibRaw handle these cases? I mean if the tag is absent and I try to access its contents what is the expected result? Or better yet, is there a good way of checking it?
I do not see EXIF GPS tags in this file.
https://drive.google.com/drive/u/1/folders/0BwHd5YdfBGISbGw3RFVCVkc0eDA
BTW no message(s) in inbox yet.....
Please use some file sharing service because E-mail providers/servers may limit message size
The Raw image i used was also in that project, near the sln file.
The only things I need is the RAW file to see is LibRaw correctly parses GPS fiield or not.
Pages