Recent comments

Reply to: Canon EOS 40D - problem with opening file   8 years 1 month ago

Followup:

metadata for this file shows:
raw data offset: 531196
raw data size: 944784

Looks strange for file only 700kb in size, so I'm sure the file was truncated.

Reply to: Canon EOS 40D - problem with opening file   8 years 1 month ago

Both FastStone and IrfanView shows embedded JPEG file. This part of image is correct.

Meanwhile, the file is exactly the same in contents (of JPEG preview) as file at rawsamples.ch. Why do you think this file is correct?

Reply to: Canon EOS 40D - problem with opening file   8 years 1 month ago

Thank you for the answer.
The size of the photo is correct - it has low resolution. I found that FastStone Image Viewer and IrfanView can open this file. Why LibRaw cannot do it?

Konrad

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

Understood.

Thanks Alex. Looking forward to playing around with this as I'm working on a project that needed support for filtering images by the usual metadata fields. Much appreciated.

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

You do not need adjust_sizes....() if you plan (or use) unpack()/dcraw_process() calls.
These calls (generally, dcraw_process()) will adjust image sizes correctly.

adjust_sizes_info_only() call is made specifically for metadata-parsing applications (take look into LibRaw/samples/raw-identify.cpp sample, this sample prints A LOT of metadata if called with -v switch)

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

Yeah, the OpenImageIO implementation doesn't offer too much flexibility, but that's understandable. Maybe for RAW files it makes sense for me to just call libraw directly.

This code path is being using while importing a large number of images into a database, so it will only ever need the metadata. Later on, when the image needs to be decoded and presented to the user, an entirely different code path is taking so the issues with adjust_sizes_info_only() shouldn't really be a problem. I'll make that call after open_file() when loading metadata but I'll make it after unpack() when preparing the image for presentation.

This is fantastic, thank you.

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

OpenImageIO::RawInput::open() do all things at one time: open, unpack, than process.

Looks like you do not need this, if you need metadata only.

LibRaw::open_file() will read all metadata, including image sizes (also, EXIF, makernotes, all).
It is really fast (fraction of second or less on SSDs)
But:
image sizes may not be completely correct if aspect ratio is not 1.0
To corect this, use asjust_sizes_info_only() call.

The bad thing that adjust_sizes_info_only() may prevent unpack()/dcraw_process() from working correctly (because sizes to be adjusted another time).
So, if you plan to call unpack() later, you'll need open_file() again.

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

Alex,

Thanks for the quick reply. If you take a look at the implementation in OpenImageIO you'll see that they call unpack() immediately after calling open_file():

https://github.com/OpenImageIO/oiio/blob/master/src/raw.imageio/rawinput...

From your comments above, it sounds like I could start reading the metadata immediately after open_file() and not call unpack() at all. Lower down, on line 285, there's a comment that indicates where the metadata reading code begins:

https://github.com/OpenImageIO/oiio/blob/master/src/raw.imageio/rawinput...

Is all of that code "safe" to call after only calling open_file()? Will valid values, if present, be correctly read? The last call to read_tiff_metadata() looks like it's just using standard OpenImageIO routines to read a TIFF header, I assume that would be OK as well?

Thanks again!

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

Followup2:

for non-square-pixel files (very old kodaks an nikons and several other cameras) you need to call adjust_sizes_info_only() call after open_file().

For most current cameras this call can be skipped.

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

Followup:

if you need to free file handle w/o releasing metadata, there is recycle_datastream() call, this call will close file handle and nothing more.

Reply to: Extracting Metadata Without Unpacking RAW Data   8 years 1 month ago

Indeed, you need only open_file() (or open_datastream() if you use it) to extract metadata.

unpack() only read and unpacks raw pixels, you do not need to use it if you need only metadata.

Also, if you need thumbnail too, you may use open_file() + unpack_thumb() calls only.

Reply to: Fujifilm Pattern with rawpy   8 years 1 month ago

Looks like rawpy incompleteness.

For X-Trans sensors (imgdata.idata.filters == 9), color pattern is contained in
imgdata.idata.xtrans (6x6 array, indexed by row%6,col%6, row and col are relative to visible area)
and in
imgdata.idata.xtrans_abs (same as above, but row/col are relative to full sensor)

Reply to: Orientation of some Canon files wrong in LibRaw 0.19-Snapshot-20170212   8 years 1 month ago

Could you please provide link to some samples?

(modern) Canon files has EXIF.Orientation tag, indeed

Reply to: Nikon Coolpix P330 - wrong black and white levels   8 years 1 month ago

The patch works. Thanks!

Reply to: Nikon Coolpix P330 - wrong black and white levels   8 years 1 month ago

Hi Alex, thanks for the patch! Will try it out.

Reply to: Nikon Coolpix P330 - wrong black and white levels   8 years 1 month ago

Here is the patch:

diff --git a/dcraw/dcraw.c b/dcraw/dcraw.c
index fb78663..87915d9 100644
--- a/dcraw/dcraw.c
+++ b/dcraw/dcraw.c
@@ -2768,7 +2768,7 @@ void CLASS unpacked_load_raw()
while (1 << ++bits < maximum)
;
read_shorts(raw_image, raw_width * raw_height);
- if (maximum < 0xffff)
+ if (maximum < 0xffff || load_flags)
for (row = 0; row < raw_height; row++)
{
#ifdef LIBRAW_LIBRARY_BUILD
diff --git a/internal/dcraw_common.cpp b/internal/dcraw_common.cpp
index 168a095..d8e22e6 100644
--- a/internal/dcraw_common.cpp
+++ b/internal/dcraw_common.cpp
@@ -2472,7 +2472,7 @@ void CLASS unpacked_load_raw()
while (1 << ++bits < maximum)
;
read_shorts(raw_image, raw_width * raw_height);
- if (maximum < 0xffff)
+ if (maximum < 0xffff || load_flags)
for (row = 0; row < raw_height; row++)
{
#ifdef LIBRAW_LIBRARY_BUILD

Reply to: Nikon Coolpix P330 - wrong black and white levels   8 years 1 month ago

but the data range is 64k

Reply to: Nikon Coolpix P330 - wrong black and white levels   8 years 1 month ago

> LibRaw 0.19 says that the black level is 205 and white level is 4095

This part is as it should be, the camera is 12-bit.

Reply to: Nikon Coolpix P330 - wrong black and white levels   8 years 1 month ago

Thanks a lot, issue confirmed

Reply to: open_bayer() creating All-Black 8-bit Images   8 years 1 month ago

Meanwhile, I could not confirm the problem.

Here is the changes made for openbayer_sample.cpp:
--- a/samples/openbayer_sample.cpp
+++ b/samples/openbayer_sample.cpp
@@ -45,7 +45,9 @@ int main(int ac, char *av[])
return 3;
LibRaw rp;
rp.imgdata.params.output_tiff = 1;
- int ret = rp.open_bayer(buffer, fsz, 640, 480, 0, 0, 0, 0, 0, LIBRAW_OPENBAYER_RGGB, 0, 0, 1400);
+ rp.imgdata.params.no_auto_bright = 1;
+ //int ret = rp.open_bayer(buffer, fsz, 640, 480, 0, 0, 0, 0, 0, LIBRAW_OPENBAYER_RGGB, 0, 0, 1400);
+ int ret = rp.open_bayer(buffer, fsz,4112,3008,0,0,0,0,0,LIBRAW_OPENBAYER_RGGB,0,0,0);
if (ret != LIBRAW_SUCCESS)
return 4;
if ((ret = rp.unpack()) != LIBRAW_SUCCESS)

(no_auto_bright=1 added to default settings).

Here is TIFF produced from your sample (screenshot in viewer): https://www.dropbox.com/s/alm7jqumy7fmf12/Screenshot%202017-08-02%2019.1...

Reply to: Demosaicing of plain RGGB data   8 years 1 month ago

Hi - to anyone else who wants to use open_bayer() before anything later than 0.18.2 is stable-released, this is a link to the Github page at the earliest (least risky) version which supports open_bayer().
https://github.com/LibRaw/LibRaw/tree/d4c4f5c8e4a2c5db56287f805d44b590ac...
This works perfectly for 16bit (EDIT: and now 8bit) RAW images without any header or metadata.

(wish I could delete comments but I can only edit them so I must look really silly with two comments in a row)

Reply to: Demosaicing of plain RGGB data   8 years 1 month ago

Alex fixed the problem with open_bayer() 8-bit images. Fix is documented here https://www.libraw.org/comment/4678#comment-4678 :)

Reply to: open_bayer() creating All-Black 8-bit Images   8 years 1 month ago

I was serious that I do color, whitebalance, exposure, etc corrections to the raw data before putting it into LibRaw. I wrote the adjustments, and only use LibRaw to demosaic. No dcraw or LibRaw emulation of dcraw involved for color-correction / whitebalance / etc.

I wish it were the case that the resulting 8bit images without auto_bright were 'near black,' but take a histogram of this result and see for yourself:
https://drive.google.com/file/d/0B41mEzFmIzubTkhfSk9zMmtVVnc/view?usp=sh...

(Output with output_bps = 8, no_auto_bright = 1, no_auto_scale = 1, user_black = 0.) Every pixel is 0, and this was an overexposed 8bit raw. Do what you will with this information; I was just trying to repay a favor, thinking I might have found unintended behavior. I see now that LibRaw uses 16bit internally, even if the input buffer was only 8 BPP.

So, what seems to be happening...
1. 8 BPP data in the buffer has max value of 255
2. The buffer is read into LibRaw, which uses 16 BPP data internally
3. no_auto_bright = 1, so values are never scaled up to 65535
4. output_bps = 8, so values are all divided by 257 to scale down to 255 maxval... but at most, we had (255 / 257), which with integer rounding down equals 0. Anything less than 255 will of course also become 0.
5. Every pixel is 0 in the resulting image!

If that's correct (?), let this post just be a warning to any 8bit - LibRaw users who read this!

Reply to: dcraw_emu - Brightness Level   8 years 1 month ago

Thank you for the explanation, and we hear you. It is just that the word "accurate" is not the one I would use.

Reply to: dcraw_emu - Brightness Level   8 years 1 month ago

Hi Iliah,
I am using dcraw_emu (as I used dcraw 9.27 previously) as a simple tool to convert a raw file to a tiff. I'm trying to keep it very simple and use existing tools created by people such as yourself who are experts in many of these things. My program acts as a controller and uses these existing tools (such as dcraw_emu) to perform specific tasks. I'm not a C programmer and thus I don't have the ability to rebuild a custom version of dcraw_emu.

My need is simple: I just need dcraw_emu to create tiff files that are good quality (color-accurate) versions of the image that was captured in the raw file. The result should be quite similar to the original embedded JPEG and to the results produced by other raw converters. In almost all cases, dcraw_emu is doing that. The greens in my X-E2 sample pictures seem to be an exception.

As a further comparison, I converted my sample file with Lightroom and with Affinity Photo (I can provide samples if you wish). The result was:
* The original embedded JPEG and the tiff file produced by dcraw 9.27 were the brightest green (almost the same).
* The version produced by Lightroom was close to the embedded JPEG but the greens weren't quite as bright.
* The Affinity Photo version was quite a bit yellower than the previous versions. I don't think that it provided a very accurate version of the greens.
* The Dcraw_emu version came out similar to the Affinity Photo version (but lighter). Converting it with the brightness turned down further might produce a very similar version to Affinity Photo.

Going back to the dcraw 9.27 color profiles could be an unnecessary step backward. In my testing of the Sony ARW files, I found that the version produced by dcraw_emu has more accurate colors than the dcraw 9.27 version (which was much yellower). Thus, for my purposes, a small change to the color profile for the X-E2 (and the other X cameras if they are the same) should give me everything that I need from dcraw_emu.

Pages