Recent comments

Reply to: LibRaw 202502 snapshot   1 month 3 weeks ago

Nikon NEFX is 4/8/16/32 shots in PixelShift mode merged via Nikon software.

Reply to: LibRaw 202502 snapshot   1 month 3 weeks ago

Dear Mat: please direct Topaz support/team to our official support E-mail (info@libraw.org)

We do not have the ability (either technical or otherwise) to provide direct support to users of programs from other vendors, but we will be happy to provide support to the vendor itself.

Reply to: Cropped dimensions mismatch   2 months 1 week ago

Awesome, thanks for looking into it.

Reply to: Cropped dimensions mismatch   2 months 1 week ago

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

Reply to: Cropped dimensions mismatch   2 months 1 week 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 1 week 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 1 week ago

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

Reply to: Cropped dimensions mismatch   2 months 1 week 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 1 week 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 week 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 week 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 week 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 week 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 2 weeks ago

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

Reply to: LibRaw 0.21 supported cameras   2 months 2 weeks 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 3 weeks ago

Thank you!

Reply to: Accessing processed image data   2 months 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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   3 months 15 hours 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   3 months 15 hours 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).

Pages