However, may I return to my questions (which were about libraw, not Topaz): When will the library be able to cope with NEF files from the Nikon Z50II? That model is not on the list of new cameras, nor formats, which is somewhat worrying, as the Z50II already is a couple of months on the market. Or is this part of NEFX (or does it come along with the support for the Z f)?
Does NEFX-support include the NEF-Format of the Nikon Z50II? Topaz doesn't open its raw files and their support claims that this would be due to libraw not supporting the new format.
Do you have a date already in mind for the release 0.22?
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.
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?
Could you please explain 'does not match'?
RAW file sample and histogram you've calculated will help.
Thanks!
Bests, Mat
The list of supported cameras will be available at the same time as the next release/snapshot. It's too early to talk about it now.
Thanks, again! But honestly, that, too, was not the primary question.
May I try to isolate it: Will the Nikon Z50II be supported in the next release? And if not, when might that be the case?
Regards,
Mat
Thanks for the quick response!
However, may I return to my questions (which were about libraw, not Topaz): When will the library be able to cope with NEF files from the Nikon Z50II? That model is not on the list of new cameras, nor formats, which is somewhat worrying, as the Z50II already is a couple of months on the market. Or is this part of NEFX (or does it come along with the support for the Z f)?
Cheers!
Hi!
Does NEFX-support include the NEF-Format of the Nikon Z50II? Topaz doesn't open its raw files and their support claims that this would be due to libraw not supporting the new format.
Do you have a date already in mind for the release 0.22?
Cheers, Mat
Nikon NEFX is 4/8/16/32 shots in PixelShift mode merged via Nikon software.
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.
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?
Pages