I cannot understand how it happens:
- you're able to access libraw_processed_image_t fields (e.g. data)
- but not able to access libraw_data_t fields (e.g. imgdata.image)
....
I don't have a solution for it at the moment. I assume it has to do something with ushort but the current Pascal wrapper doesn't contain a reference to it. I can only hope Laheller has a solution for it.
ushort (*image)[4];
The memory area that contains the image pixels per se. It is filled when raw2image() or dcraw_process() is called.
make_mem_image() is not targeted to make copy of intermediate state if imgdata.image[] content.
it is targeted to create 3-component image (RGB) from 4-component imgdata.image (also, rotation, 16-8 bit conversion and gamma curve is applied).
make_mem_image() assumes that all processing is already done, so RGB image is contained in first 3 components of 4-component imgdata.image[][4] pixel.
If one need to access unmodified imgdata.image data it should be done directly.
Fujifilm X-Trans (6x6 pattern) files are 3-component, there is no 'second green'.
There is no way to get separate image planes via LibRaw:
- unprocessed data (assuming we're talking about bayer/xtrans camera) is single layer
- intermediate data(after LibRaw::raw2image) is a 4-component per pixel interleaved (4th component is not used in X-trans case)
Maybe Alex can clarify:
Why is the second green missing and how to fix? Having the raw packed in a three color image is not a problem but the missing second green is a problem.
Is this the LibRaw standard way for getting unprocessed raw: "getting three buffers: RED, GREEN, and BLUE. All buffers have the same sizes (size of the image) but with “holes” in the place of other colors pixels." or is a better way?
And what is also puzzling is in an other program setting libraw_set_output_color(handler, LibRaw_output_color.raw); doesn't do anything either.
Sony/compressed (ARW2.3) linearization curve is applied on LibRaw::unpack() phase.
Curve is accessible via imgdata.color.curve[] array (also, one could use RawDigger application to dump linearization curve)
I was looking into confirming if the linearization table given for a number of files is "correct". For ARW files, I was hoping to compare it to linearization data retrieved from dcraw; or to check to see if the raw cfa data has applied the linearization table correctly; however both libraw and dcraw do not seem to apply the linearization table for ARW files, nor is there a command I can run (that I know of) with dcraw to get the linearization table. I was curious if you knew the best means of confirming the correctness of the linearization table output for an ARW file/was curious how you have done so yourselves.
cdesc describes color index to color name translation, this is not pattern.
LibRaw::COLOR(row,col) returns color index for given row,col; It is not the same for LibRaw 0.19 and 0.20, please recheck (at least, imgdata.idata.filters are different, so COLOR() output should be different also)
Finally I figured out how to correctly dump memory image to Windows Bitmap file.
Simple we need add some padding bytes after each line before saving to Bitmap.
Number of padding bytes is given by following formula:
num = img.width mod 4
Since I did everything in C# language, including a wrapper around LibRaw library, I can provide only C# sample code:
var num = img.width % 4;
var padding = new byte[num];
var stride = img.width * img.colors * (img.bits / 8);
var line = new byte[stride];
var tmp = new List<byte>();
for (var i = 0; i < img.height; i++) {
// BlockCopy: src, srcIndex, dst, dstIndex, count
Buffer.BlockCopy(img.data, stride * i, line, 0, stride);
tmp.AddRange(line);
tmp.AddRange(padding);
}
tmp.ToArray(); // this will contain the correct data ready for export to Bitmap
I cannot understand how it happens:
- you're able to access libraw_processed_image_t fields (e.g. data)
- but not able to access libraw_data_t fields (e.g. imgdata.image)
....
I don't have a solution for it at the moment. I assume it has to do something with ushort but the current Pascal wrapper doesn't contain a reference to it. I can only hope Laheller has a solution for it.
ushort (*image)[4];
The memory area that contains the image pixels per se. It is filled when raw2image() or dcraw_process() is called.
??? Your code is calling raw2image, but not calling dcraw_process().....
Also, current processing stage is reflected in imgdata.progress_flags
Thanks.for the info. But how to detect where the image data is after raw2mem?
Understood the problem.
make_mem_image() is not targeted to make copy of intermediate state if imgdata.image[] content.
it is targeted to create 3-component image (RGB) from 4-component imgdata.image (also, rotation, 16-8 bit conversion and gamma curve is applied).
make_mem_image() assumes that all processing is already done, so RGB image is contained in first 3 components of 4-component imgdata.image[][4] pixel.
If one need to access unmodified imgdata.image data it should be done directly.
I have tried two camera images:
CR2, EOS 80D
CR3, EOS R
unprocessed_raw.exe writes normal raws. The 3 layer format is not a problem but then missing second green, G2 is essential
Han, what camera files do you test with?
Fujifilm X-Trans (6x6 pattern) files are 3-component, there is no 'second green'.
There is no way to get separate image planes via LibRaw:
- unprocessed data (assuming we're talking about bayer/xtrans camera) is single layer
- intermediate data(after LibRaw::raw2image) is a 4-component per pixel interleaved (4th component is not used in X-trans case)
Laheller, thanks for the wrapper. It works for colour images but at the moment not for extracting unprocessed raw.
The second green color is missing. I get RGB0 where 0 stand for zero value. See this screen shot.
https://ibb.co/d0TD6Lv
I do the following
libraw_open_file
libraw_unpack
libraw_raw2image
libraw_dcraw_make_mem_image
Maybe Alex can clarify:
Why is the second green missing and how to fix? Having the raw packed in a three color image is not a problem but the missing second green is a problem.
Is this the LibRaw standard way for getting unprocessed raw: "getting three buffers: RED, GREEN, and BLUE. All buffers have the same sizes (size of the image) but with “holes” in the place of other colors pixels." or is a better way?
And what is also puzzling is in an other program setting libraw_set_output_color(handler, LibRaw_output_color.raw); doesn't do anything either.
Han
You may need to recompile libraw samples using older version of XCode.
make -f Makefile.dist
should do that
Yes that fixes it. :)
>>What version of Mac OS X/macOS do you use?
High Sierra, 10.12
What version of Mac OS X/macOS do you use?
ASTAP a free application for processing astronomical images uses unprocessed_raw.
http://www.hnsky.org/astap.htm
Thanks for providing LibRaw.
Han
Usually we publish snapshots (or releases) every 5-7 months. LibRaw 0.20 was released in July, so....
Any idea when the next development snapshot will be?
EOS R5 is not supported by 0.20, see supported camera list: https://www.libraw.org/supported-cameras
R5 support is expected in next development snapshot.
Sony/compressed (ARW2.3) linearization curve is applied on LibRaw::unpack() phase.
Curve is accessible via imgdata.color.curve[] array (also, one could use RawDigger application to dump linearization curve)
I was looking into confirming if the linearization table given for a number of files is "correct". For ARW files, I was hoping to compare it to linearization data retrieved from dcraw; or to check to see if the raw cfa data has applied the linearization table correctly; however both libraw and dcraw do not seem to apply the linearization table for ARW files, nor is there a command I can run (that I know of) with dcraw to get the linearization table. I was curious if you knew the best means of confirming the correctness of the linearization table output for an ARW file/was curious how you have done so yourselves.
cdesc describes color index to color name translation, this is not pattern.
LibRaw::COLOR(row,col) returns color index for given row,col; It is not the same for LibRaw 0.19 and 0.20, please recheck (at least, imgdata.idata.filters are different, so COLOR() output should be different also)
I just created a FreePascal wrapper for libraw, but is should work also in Delphi, so here you go:
https://github.com/laheller/FPLibRaw
Finally I figured out how to correctly dump memory image to Windows Bitmap file.
Simple we need add some padding bytes after each line before saving to Bitmap.
Number of padding bytes is given by following formula:
Since I did everything in C# language, including a wrapper around LibRaw library, I can provide only C# sample code:
var num = img.width % 4; var padding = new byte[num]; var stride = img.width * img.colors * (img.bits / 8); var line = new byte[stride]; var tmp = new List<byte>(); for (var i = 0; i < img.height; i++) { // BlockCopy: src, srcIndex, dst, dstIndex, count Buffer.BlockCopy(img.data, stride * i, line, 0, stride); tmp.AddRange(line); tmp.AddRange(padding); } tmp.ToArray(); // this will contain the correct data ready for export to BitmapPicture Window Pro 8 - a free advanced image editor for Windows - now uses LibRaw to open raw files.
www.dl-c.com
Monochrome2DNG does more than you described.
Thank you for reporting, fixed/cleaned up by this: https://github.com/LibRaw/LibRaw/commit/37c7b517c177e4e89ae8f95baed0b2a3...
https://www.dropbox.com/s/19dm6nmr47fg0ua/raw_leaf_aptus_22.mos.ppm?dl=0
Pages