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
Alex,
I am using 0.19.6 version + I am on Windows. I will look into my code and confirm my implementation is correct. Would it be possible for you to send me the PPM files for me to compare?
OUT.use_camera_wb = 1; // Use As Shot White Balance
OUT.output_bps = 16; // 16-bit output
OUT.no_auto_bright = 1; // Do not contrast stretch the image
OUT.output_color = 1; // sRGB space
OUT.gamm[0] = 1/2.4; // power for sRGB
OUT.gamm[1] = 12.92; // toe slope for sRGB
Hi Alex,
Thanks for confirming the settings are the same and for updating the help. However, I am getting differences for a RAW file from LEAF. I am providing a link to the file below:
My workflow is
open_file()
unpack()
// Set the imgdata.params as described above
get_mem_image_format(...)
dcraw_process()
dcraw_make_mem_image()
// Copy the rendered image
According to Remarks section of this page:
The stride is the width of a single row of pixels (a scan line), rounded up to a four-byte boundary. If the stride is positive, the bitmap is top-down. If the stride is negative, the bitmap is bottom-up.
So maybe yes, it could be an alignment problem. Otherwise I have no idea, why it doesn't work.
If windows bitmap rows are aligned full data copy (not per-line copy) will result into 'lost sync' image, because libraw_processed_image_t data is not aligned, but rows are packed w/o gaps.
It's not about C#. I am just calling the C methods provided by Libraw. I do not even change the bytes in data field of libraw_processed_image_t, just simply copying it to the memory allocated for Windows Bitmap.
BTW I forgot to mention that also using following Libraw setter methods for process:
libraw_set_output_bps -> 8
libraw_set_output_color -> 0
Update:
Also tried the libraw_dcraw_ppm_tiff_writer method using TIFF option which creates a correct, color TIFF file!
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
Alex,
I am using 0.19.6 version + I am on Windows. I will look into my code and confirm my implementation is correct. Would it be possible for you to send me the PPM files for me to compare?
Regards,
Dinesh
Cloned your settings into mem_image_sample.cpp:
compared with
Results are the same:
Fixed the link permissions. Here is the link again:
https://drive.google.com/file/d/1HkNwHiFGjRaz7y6nd6lWlO6W0BVE5p1z/view?u...
Dinesh
Link is not accessible
Hi Alex,
Thanks for confirming the settings are the same and for updating the help. However, I am getting differences for a RAW file from LEAF. I am providing a link to the file below:
https://drive.google.com/file/d/1HkNwHiFGjRaz7y6nd6lWlO6W0BVE5p1z/view?u...
My workflow is
open_file()
unpack()
// Set the imgdata.params as described above
get_mem_image_format(...)
dcraw_process()
dcraw_make_mem_image()
// Copy the rendered image
For a NEF file in my possession, it works fine.
Regards,
Dinesh
Fixed by https://github.com/LibRaw/LibRaw/commit/c6339c13a991571822518d13e7288012...
dcraw_emu uses same dcraw_process() call, so with same parameters output should be the same.
-6 results in 16-bit output:
case '6':
OUT.output_bps = 16;
break;
(looks like docs need to be corrected)
Can anybody help me with that?
How to create a windows bitmap using data field from libraw_processed_image_t structure?
According to Remarks section of this page:
The stride is the width of a single row of pixels (a scan line), rounded up to a four-byte boundary. If the stride is positive, the bitmap is top-down. If the stride is negative, the bitmap is bottom-up.
So maybe yes, it could be an alignment problem. Otherwise I have no idea, why it doesn't work.
If windows bitmap rows are aligned full data copy (not per-line copy) will result into 'lost sync' image, because libraw_processed_image_t data is not aligned, but rows are packed w/o gaps.
It's not about C#. I am just calling the C methods provided by Libraw. I do not even change the bytes in data field of libraw_processed_image_t, just simply copying it to the memory allocated for Windows Bitmap.
BTW I forgot to mention that also using following Libraw setter methods for process:
libraw_set_output_bps -> 8
libraw_set_output_color -> 0
Update:
Also tried the libraw_dcraw_ppm_tiff_writer method using TIFF option which creates a correct, color TIFF file!
Pages