Recent comments

Reply to: Cropped dimensions mismatch   2 months 3 hours ago

I see, so that's the expected behavior, thanks for clarifying.

Reply to: Cropped dimensions mismatch   2 months 3 hours ago

In fact, adjust_to_raw_inset_crop will ignore this incorrect crop, so problem is minor: https://github.com/LibRaw/LibRaw/blob/master/src/utils/utils_libraw.cpp#...

Reply to: Cropped dimensions mismatch   2 months 4 hours ago

Thanks: look like a bug: inset_crop ajusted twice: DNG metadata (DefaultCrop tag) and Canon visible area metadata.

Reply to: Cropped dimensions mismatch   2 months 4 hours ago

If left (or top) margin is adjusted by one: this results into visible area adjustment too...

Reply to: Cropped dimensions mismatch   2 months 4 hours ago

Thanks for your replies and for looking into it (and for the library as well).

To add to the DNG, CR2 question - you are right - TIFF from DNG and TIFF from CR2 have matching resolution 5634x3752 which seems to map to width, height from the libraw_image_sizes_t structure.

Also raw-identify -f -u reports the same raw_height, raw_width resolutions for both DNG and CR2: 5792x3804.

What is differing is the line starting with Raw inset, width x height: matching libraw_raw_inset_crop_t when using raw-identify -v on both DNG and CR2: offsets in CR2 are 168, 56 and for DNG are 336, 112. The DNGs offsets are too large - e.g. trying to crop raw area with them would not be possible. I think I'd expect offsets of both DNG and CR2 match (cropped resolution matches).

Reply to: Cropped dimensions mismatch   2 months 4 hours ago

Ah, that makes sense about the left/top margins to align with bayer pattern.

What about the cropped resolution though? Shouldn't it match what ExifTool reports? E.g. LibRaw's 3007 x 1999 vs ExifTool's 3008 x 2000.

I'm wondering if the decreased resolution is caused by the left/top alignment, or it's an unrelated issue.

Reply to: Cropped dimensions mismatch   2 months 1 day ago

Framing is also the same:
$ raw-identify -f -u *

RAW_CANON_5DMARK2_PREPROD.CR2 lossless_jpeg_load_raw() F=158x52x0x0 RS=5792x3804 Canon/EOS 5D Mark II
RAW_CANON_5DMARK2_PREPROD777.dng packed_dng_load_raw() F=158x52x0x0 RS=5792x3804 Canon/EOS 5D Mark II

Reply to: Cropped dimensions mismatch   2 months 1 day ago

Regarding RAW_CANON_5DMARK2_PREPROD.CR2 file:
1) Converted it to DNG using current Adobe DNG Converter (17.2)
2) processed w/ dcraw_emu -T -w (dcraw_emu: from github/LibRaw/master)

Results are the same in size, 5634x3752
TIFF from CR2: https://www.dropbox.com/scl/fi/61ug0bh598av2plhbgheq/RAW_CANON_5DMARK2_P...

TIFF from DNG: https://www.dropbox.com/scl/fi/c97oua0z5vpiaksnhk418/RAW_CANON_5DMARK2_P...

Reply to: Cropped dimensions mismatch   2 months 1 day ago

Left/top margins are always adjusted to multiply of 2 (of 6 for Fuji X-Trans) to keep bayer pattern the same for both full sensor area and visible area.

Reply to: Cropped dimensions mismatch   2 months 1 day ago

Another issue I came across is that the cropped dimension offsets are different between a CR2 image and a corresponding DNG.

CR2: https://github.com/letmaik/rawpy/blob/main/test/RAW_CANON_5DMARK2_PREPRO... and a DNG is obtained by using Adobe DNG Converter (17.1.0).

CR2: 5616 x 3744 left: 168 top: 56
DNG: 5616 x 3744 left: 336 top: 112

CR2's raw resolution is 5792x3804, so trying to crop it according to those values would not be possible - it'd escape the raw dimensions (e.g. 336 + 5616 > 5792).

It's also interesting that DNG's offsets are exactly double of those reported for CR2.

I found a note here https://www.libraw.org/news/libraw-202110-snapshot that this might be expected, but wanted to flag it anyway in case it'd offer you some additional clues.

Reply to: LibRaw 0.21 supported cameras   2 months 3 days ago

our release policy is published on this site frontpage: https://www.libraw.org/#updatepolicy

Reply to: LibRaw 0.21 supported cameras   2 months 3 days ago

Hello LibRaw,

Could you advise when Sony ILCE-7CM2 (A7C II) will be supported in release?

We cannot find it in 0.21.3 release but in 202403 snapshot.

Thank you very much in advance.

Reply to: Accessing processed image data   2 months 1 week ago

Thank you!

Reply to: Accessing processed image data   2 months 1 week ago

You can assume that this is pixel0R, pixel0G, pixel0B.... each value is 16-bit unsigned integer datatype in your CPU byte order.

Reply to: Accessing processed image data   2 months 1 week ago

Thanks for quick reply.
So can I assume that for 16bit RGB data the order of bytes will be:
pixel0-R-LSbyte, pixel0-R-MSbyte, pixel0-G-LSbyte, pixel0-G-MSbyte, pixel0-B-LSbyte, pixel0-B-MSbyte, pixel1-R-LSbyte, and so on?

Reply to: Accessing processed image data   2 months 1 week ago

Yes, data[1] is to make it 'in place array' (no additional indirection level)

It is allocated via this code:

  int stride = width * (bps / 8) * colors;
  unsigned ds = height * stride;
  libraw_processed_image_t *ret = (libraw_processed_image_t *)::malloc(
      sizeof(libraw_processed_image_t) + ds);
Reply to: Unknown error code (0x16) returned by libraw_dcraw_process()   2 months 1 week ago

Sorry, that turned out to be a weird JNA issue rather than with LibRaw.

Reply to: Unknown error code (0x16) returned by libraw_dcraw_process()   2 months 1 week ago

All LibRaw::dcraw_process() return codes are negative.

A quick look at the source code showed no deviations from this rule.

Could you please provide raw file you're testing with

Reply to: JNA wrappers for LibRaw   2 months 1 week ago

Just to conclude this thread: I found my bug - a missing member in one of the makernotes classes. Now getting correct raw data in raw_image.

Reply to: JNA wrappers for LibRaw   2 months 2 weeks ago

Also you may start with simple C-language sample (just print non-zero pointer) to make sure it works on C side.

Reply to: JNA wrappers for LibRaw   2 months 2 weeks ago

You need to ensure you use same data types definitions (.h files) and same structure alignment in both
- your code (that calculates offsets of imgdata.rawdata members during your code compilation)
- and LibRaw library (offsets calculated by compiler at library build stage).

Reply to: JNA wrappers for LibRaw   2 months 2 weeks ago

Thanks for the prompt reply. Sorry, I should have provided a more complete problem statement (but where do you stop?) My code tests all the different data raw data pointers in libraw_rawdata_t and they are all null. I'm testing with Canon CR2 and Panasonic RW2. I assume unpack has done its job since it returned no error and libraw_image_sizes_t.raw_pitch has (what seems like) valid data (which it didn't have before the unpack).

Reply to: JNA wrappers for LibRaw   2 months 2 weeks ago

Sorry, know nothing about JAVA, JNA, etc.

As mentioned in documentation: 'After call to unpack() only one of these fields is non-NULL.': https://www.libraw.org/docs/API-datastruct-eng.html#libraw_rawdata_t

Which one: depends of raw file you're unpacking.

Reply to: I don't understand why I get only 2 components data in all pixels   2 months 3 weeks ago

For anyone that reaches this topic at some point, and are facing the exact same problem, here is what seems to be the fix. At least, it seems to fixed the problem for me. As Alex described, the problem seems to be in how I built the Libraw library in my machine. I just made a brand new clone of the Libraw repo, and I built the library from source again, following the steps described in the INSTALL file: https://github.com/LibRaw/LibRaw/blob/master/INSTALL

Then, I payed close attention in the compiler flags that were used in the Makefile that was generated by automake. Then, I changed the build command in my Makefile to use the same compiler flags that were used in the Makefile that was generated by the automake. As a result, I got this Makefile:

gcc main.c -g -lraw -pthread -O2 -fopenmp -ljpeg -lz -llcms2 -lm -fPIC

There are still some issues in the results, but it is already much better with this change.

Pages