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).
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
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)
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.
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.
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?
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).
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).
Awesome, thanks for looking into it.
I see, so that's the expected behavior, thanks for clarifying.
This patch should fix it: https://github.com/LibRaw/LibRaw/commit/29d9785c2d5f71db7c6ae2834003cd21...
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#...
Thanks: look like a bug: inset_crop ajusted twice: DNG metadata (DefaultCrop tag) and Canon visible area metadata.
If left (or top) margin is adjusted by one: this results into visible area adjustment too...
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, heightfrom thelibraw_image_sizes_tstructure.Also
raw-identify -f -ureports the sameraw_height, raw_widthresolutions for both DNG and CR2: 5792x3804.What is differing is the line starting with
Raw inset, width x height:matchinglibraw_raw_inset_crop_twhen usingraw-identify -von 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).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.
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
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...
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.
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: 56DNG:
5616 x 3744 left: 336 top: 112CR2'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.
our release policy is published on this site frontpage: https://www.libraw.org/#updatepolicy
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.
Thank you!
You can assume that this is pixel0R, pixel0G, pixel0B.... each value is 16-bit unsigned integer datatype in your CPU byte order.
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?
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);Sorry, that turned out to be a weird JNA issue rather than with LibRaw.
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
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.
Also you may start with simple C-language sample (just print non-zero pointer) to make sure it works on C side.
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).
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).
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.
Pages