LibRAW does support Leica M11 (triple sensor as the Q3, interchangeable lens), Leica Q, Leica Q-P and Leica Q2 (different sensor, fixed lens, and look like the lens iare the same in the Q series, but switching from one to another the behavior is different). Anyway all them use DNG, so I think that some differencies does exists. Probably (just my idea) that the M11 is very similar to Q3, but can't say this for sure.
In any case, without neither an entry of the Q3 in LibRAW (even if identical to M11), the software which uses the library can't understand what camera is and does not act consequently, forcing to manually select a "similar" lens/camera to proceed.
Also using Adobe DNG converter (without compression, of course) the converted file (Leica DNG to Adobe DNG) size is quite different, so I suppose that Leica DNG are in some way not equal to Adobe format.
I'm not an expert of raw file structure, but I believe that something is different.
This file is recorded using 'Sony YCC pseudo-raw' (Small/Medium RAW).
This format is not supported by LibRaw 0.21 (and will be supported in the next 'public snapshot').
The format was introduced after A7-IV release via firmware update; that's why this camera is listed as supported while it is really partially supported: at the time of the release of Librav 0.21, this recording format did not yet exist for this camera.
This is the first time I've heard anyone refer to "raw" and "RAW" as different things. I use these terms interchangeably, and sometimes "Raw". To me, they all refer to the pixel data encoded in the file. And recovering that pixel data is what a raw decoder is for.
Can you expand a bit on what kind of processing you're referring to with "RAW" data? I know that lossy compression can be applied. So in that sense, yes, I understand that the RAW file loses some information.
I've done more reading on the subject. For one thing, the radiometric response function is also called the camera response function. There are (at least) a couple of references to linearization in DNG. Neither of these is related to the RRF.
There are many papers on the subject of inverting or reversing the camera capture pipeline. That is, starting from the RAW file, applying inverse transforms to recover the sensor irradiance at each pixel.
I think that is the kind of thing I'm looking for. So it would appear that a simple RAW decoder—one that simply decodes and decompresses a camera RAW file—neither applies nor unapplies a RRF. That is, unless it's part of some particular camera's inherent RAW processing. However, that does not appear to be the case with NEF, at least.
These days consumer cameras don't record raw, they record RAW. Big difference, as RAW is processed, sometimes heavily, sometimes using lossy compression.
We don't know of a general answer to this question that will always work.
For example:
Some previews (on some cameras) contain a black border on the right/left, which is not part of the RAW image, so no pixel in RAW corresponds to the left-top (or any) preview image corner.
The lens geometry correction has been applied to the preview, so its edges do not correspond to any straight horizontal/vertical line in the RAW
Aspect ratio in the preview may be not exactly the same as RAW image area.
In some cases imgdata.sizes.raw_inset_crops[..] may work.
Dear Alex,
first of all, many thanks for the wonderful libraw and your effort.
I'm currently dealing with Canon R5 CR3.
I can sucessfully decode the largest thumbnail(JPEG 1620x1080) using this following code.
//--------------------
rawp->unpack_thumb_ex(1);
rawimgthumb = rawp->dcraw_make_mem_thumb(&err); //store unpacked and processed raw image
Howerver, it seems that the start pxiel(left-top conner) of the decoded thumbnail image is not the same of the start pixel of the raw image(8191x5463 or with frame 8352x5586).
How can we match the exackt position between the thumbnail and the raw image?
Is there any parameter about the croping region of the thumbnail from raw image?
tried the 64-bit version and it worked fine, but using the compiled 32-bit version had issue. don't know why. i'll try to investigate on this more (maybe some configuration issues on my side). are there difference between 64 and 32?
I have tried to add some options like "-t 5 -Z -" (flip 90 CCW and output to stdout), but it seems like it doesn't apply the flip on the output. am i missing something?
GoPro cameras are supported for a long time via GoPro SDK + DNG SDK wrapper built in LibRaw.
We're not responsible for any Topaz product, please direct your questions to vendor support.
Hello,
Is it possible or is it planned that go pro raw format gpr. could be processed by Topaz?
It would be great for uw photos :-)
Thanks for the fast answer!
Some consideration:
LibRAW does support Leica M11 (triple sensor as the Q3, interchangeable lens), Leica Q, Leica Q-P and Leica Q2 (different sensor, fixed lens, and look like the lens iare the same in the Q series, but switching from one to another the behavior is different). Anyway all them use DNG, so I think that some differencies does exists. Probably (just my idea) that the M11 is very similar to Q3, but can't say this for sure.
In any case, without neither an entry of the Q3 in LibRAW (even if identical to M11), the software which uses the library can't understand what camera is and does not act consequently, forcing to manually select a "similar" lens/camera to proceed.
Also using Adobe DNG converter (without compression, of course) the converted file (Leica DNG to Adobe DNG) size is quite different, so I suppose that Leica DNG are in some way not equal to Adobe format.
I'm not an expert of raw file structure, but I believe that something is different.
Again thanks for your attention!
Denebola
Leica records (standard) DNG files, is some specific support really needed for Q3?
Next public snapshot with X-S20 support will be published on schedule: https://www.libraw.org/#updatepolicy
wow! I got it, wait for Libraw support it, thx!
This file is recorded using 'Sony YCC pseudo-raw' (Small/Medium RAW).
This format is not supported by LibRaw 0.21 (and will be supported in the next 'public snapshot').
The format was introduced after A7-IV release via firmware update; that's why this camera is listed as supported while it is really partially supported: at the time of the release of Librav 0.21, this recording format did not yet exist for this camera.
Use get_decoder_info() ( https://www.libraw.org/docs/API-CXX.html#get_decoder_info ) and check either decoder_name against "nikon_he_load_raw_placeholder()" or decoder_flags bit LIBRAW_DECODER_UNSUPPORTED_FORMAT
How can we detect or check whether a particular image file is in the HE/HE* format?
Hi Iliah,
This is the first time I've heard anyone refer to "raw" and "RAW" as different things. I use these terms interchangeably, and sometimes "Raw". To me, they all refer to the pixel data encoded in the file. And recovering that pixel data is what a raw decoder is for.
Can you expand a bit on what kind of processing you're referring to with "RAW" data? I know that lossy compression can be applied. So in that sense, yes, I understand that the RAW file loses some information.
Cheers.
> a simple RAW decoder—one that simply decodes and decompresses a camera RAW file—neither applies nor unapplies a RRF
Correct.
> unless it's part of some particular camera's inherent RAW processing. However, that does not appear to be the case with NEF, at least.
White balance pre-conditioning? Noise reduction? Tricks with black level? etc, etc...
I've done more reading on the subject. For one thing, the radiometric response function is also called the camera response function. There are (at least) a couple of references to linearization in DNG. Neither of these is related to the RRF.
There are many papers on the subject of inverting or reversing the camera capture pipeline. That is, starting from the RAW file, applying inverse transforms to recover the sensor irradiance at each pixel.
I think that is the kind of thing I'm looking for. So it would appear that a simple RAW decoder—one that simply decodes and decompresses a camera RAW file—neither applies nor unapplies a RRF. That is, unless it's part of some particular camera's inherent RAW processing. However, that does not appear to be the case with NEF, at least.
Cheers.
These days consumer cameras don't record raw, they record RAW. Big difference, as RAW is processed, sometimes heavily, sometimes using lossy compression.
Unprocessed /linearized RAW values (after LibRaw::unpack() ) is probably what is you're looking for.
RawSpeed licensing is out of our control, if it is licensed under LGPL terms we're unable to change it
many thnaks for the prompt response.
i'll try to test the parameter imgdata.sizes.raw_inset_crops[..].
best regards.
We don't know of a general answer to this question that will always work.
For example:
In some cases imgdata.sizes.raw_inset_crops[..] may work.
Dear Alex,
first of all, many thanks for the wonderful libraw and your effort.
I'm currently dealing with Canon R5 CR3.
I can sucessfully decode the largest thumbnail(JPEG 1620x1080) using this following code.
//--------------------
rawp->unpack_thumb_ex(1);
rawimgthumb = rawp->dcraw_make_mem_thumb(&err); //store unpacked and processed raw image
Mat rawData(1, rawimgthumb->data_size, CV_8UC1, (void*)rawp->imgdata.thumbnail.thumb);
thumbimg_file = imdecode(rawData, 1); //BGR
//--------------------
Howerver, it seems that the start pxiel(left-top conner) of the decoded thumbnail image is not the same of the start pixel of the raw image(8191x5463 or with frame 8352x5586).
How can we match the exackt position between the thumbnail and the raw image?
Is there any parameter about the croping region of the thumbnail from raw image?
Thank you for your response in advance.
Kim
The file is a lossy compressed dng image. I have attached it here, https://drive.google.com/file/d/18QaZiL_YBEXwrmKd9638zHuWpOo54V5y/view
I have compiled in 32-bit with USE_JPEG enabled, linked with libjpeg library
I was able to decode using "-Z -". But adding additional options such as " -w -H 0 -o 0 -Z -" prints "Request for nonexisting image number"
Generally, there shouldn't be a difference between 32- and 64-bit versions.
In practice, 32-bit builds have not been tested for a long time.
Could you please provide the RAW file you're testing with: for analysis
tried the 64-bit version and it worked fine, but using the compiled 32-bit version had issue. don't know why. i'll try to investigate on this more (maybe some configuration issues on my side). are there difference between 64 and 32?
Works for me: dcraw_emu.exe -t 5 -Z - filename >0.ppm
(-T ... > 0.tif works too)
I have tried to add some options like "-t 5 -Z -" (flip 90 CCW and output to stdout), but it seems like it doesn't apply the flip on the output. am i missing something?
"-Z -" command worked great for me! Thanks a lot!
dcraw_emu w/o args displays:
suf => replace input filename last extension
- => output to stdout
filename.suf => output to filename.suf
is that what you were asking about?
Pages