Hello,
while testing https://github.com/letmaik/rawpy/pull/252 I've noticed some inconsistencies and would like to ask about them here. I suspect some might be bugs.
When checking dimensions of this image https://data.csail.mit.edu/graphics/fivek/img/dng/a0001-jmac_DSC1459.dng, LibRaw's dimensions are off by one.
LibRaw (0.21.3): 3007 x 1999 left: 16 top: 8
Checked with raw-identify -v
and looked for line starting with Raw inset, width x height:
.
ExifTool:
[TIFF-IFD0-SubIFD] DefaultCropOrigin : 15 7 [TIFF-IFD0-SubIFD] DefaultCropSize : 3008 2000
Checked with exiftool -a -G5 -s
. (exiv2 reports the same values)
Best,
Juraj
Another issue I came across
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.
Left/top margins are always
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.
-- Alex Tutubalin @LibRaw LLC
Ah, that makes sense about
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.
If left (or top) margin is
If left (or top) margin is adjusted by one: this results into visible area adjustment too...
-- Alex Tutubalin @LibRaw LLC
I see, so that's the expected
I see, so that's the expected behavior, thanks for clarifying.
Regarding RAW_CANON_5DMARK2
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...
-- Alex Tutubalin @LibRaw LLC
Framing is also the same:
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
-- Alex Tutubalin @LibRaw LLC
Thanks for your replies and
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 thelibraw_image_sizes_t
structure.Also
raw-identify -f -u
reports the sameraw_height, raw_width
resolutions for both DNG and CR2: 5792x3804.What is differing is the line starting with
Raw inset, width x height:
matchinglibraw_raw_inset_crop_t
when usingraw-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).Thanks: look like a bug:
Thanks: look like a bug: inset_crop ajusted twice: DNG metadata (DefaultCrop tag) and Canon visible area metadata.
-- Alex Tutubalin @LibRaw LLC
In fact, adjust_to_raw_inset
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#...
-- Alex Tutubalin @LibRaw LLC
This patch should fix it:
This patch should fix it: https://github.com/LibRaw/LibRaw/commit/29d9785c2d5f71db7c6ae2834003cd21...
-- Alex Tutubalin @LibRaw LLC
Awesome, thanks for looking
Awesome, thanks for looking into it.