Recent comments

Reply to: Hasselblad 3FR opens black   4 days 23 hours ago

Thanks - I will recheck.

Reply to: Hasselblad 3FR opens black   4 days 23 hours ago

The file also contains absolutely black preview.
Adobe DNG Converter converts it to absolutely black DNG file.
zip compresses it into 300k zipfile (1:100 compression ratio)

Are you sure the file is not completely black, but contains some image?

Reply to: DNG with jpeg-xl compresseion   1 week 3 days ago

1) We're aware
2) Yes it will be supported
3) It will be supported via Adobe DNG SDK Integration

Reply to: Z 9 HE/HE* formats support plans   2 weeks 5 days ago

There is a FFDShow add-on for the new JPEG-XS on GitHub, but I guess it won't read the .nef files. Or looking at it, might even introduce licensing problems? :-)

But how are you coming along? If you need sample files, I am happy to provide (Z8 files).

Reply to: Adobe DNG Gainmap support or extraction   4 weeks 1 day ago

Thank you very much for the reply. Hopefully this is what I'm looking for.
All the best.

Reply to: Adobe DNG Gainmap support or extraction   4 weeks 1 day ago

Assuming you're talking about OpcodeList#, not ProfileGainTableMap (introduced in DNG 1.6).

If LibRaw is compiled with Adobe DNG SDK: it is possible to process via DNG Stage2/Stage3 by specifying corresponding rawoption bits:

Process Stage2/3 only if OpcodeList2/3 present: LIBRAW_RAWOPTIONS_DNG_STAGE2_IFPRESENT,LIBRAW_RAWOPTIONS_DNG_STAGE3_IFPRESENT

Forced Stage2/3 processing: LIBRAW_RAWOPTIONS_DNG_STAGE2 and
LIBRAW_RAWOPTIONS_DNG_STAGE3

If one want to extract specific DNG/TIFF/EXIF tags: use exifparser_handler to setup own callback function.

Reply to: Libraw to be used for iOS app   1 month 2 weeks ago

Sorry, but I don’t understand what exactly your problem is.
.a files are meant to be (statically) linked to your application, what do you mean for "does not remain accessible"? Accessible for what?

In any case, you can build the library as a shared one

Reply to: libraw_internal_data access   2 months 1 week ago

Using any internal (non-documented) fields in a class may lead to a rewrite of your application when the next version of the library is released. We treat public/documented fields much more carefully (although there is no complete guarantee that they will never change).

However, internal fields are declared as protected:, not private: (specifically for the case you described), so you can implement your own derived class that will provide the necessary access from the outside

Reply to: LibRaw 0.21 supported cameras   2 months 1 week ago

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.

Reply to: LibRaw 0.21 supported cameras   2 months 1 week ago

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 :-)

Reply to: Leica Q3 support?   3 months 4 weeks ago

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

Reply to: Leica Q3 support?   3 months 4 weeks ago

Leica records (standard) DNG files, is some specific support really needed for Q3?

Reply to: Fuji X-S20 Support   4 months 1 week ago

Next public snapshot with X-S20 support will be published on schedule: https://www.libraw.org/#updatepolicy

Reply to: Sony ARW file use libraw_open_file return -2 error code.   4 months 2 weeks ago

wow! I got it, wait for Libraw support it, thx!

Reply to: Sony ARW file use libraw_open_file return -2 error code.   4 months 2 weeks ago

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.

Reply to: Support for Nikon Z8   4 months 3 weeks ago

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

Reply to: Support for Nikon Z8   4 months 3 weeks ago

How can we detect or check whether a particular image file is in the HE/HE* format?

Reply to: Libraw and the radiometric response function   5 months 2 weeks ago

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.

Reply to: Libraw and the radiometric response function   5 months 2 weeks ago

> 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...

Reply to: Libraw and the radiometric response function   5 months 2 weeks ago

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.

Reply to: Libraw and the radiometric response function   5 months 2 weeks ago

These days consumer cameras don't record raw, they record RAW. Big difference, as RAW is processed, sometimes heavily, sometimes using lossy compression.

Reply to: Libraw and the radiometric response function   5 months 2 weeks ago

Unprocessed /linearized RAW values (after LibRaw::unpack() ) is probably what is you're looking for.

Reply to: RawSpeed Licensing vs. CDDL LibRaw   5 months 2 weeks ago

RawSpeed licensing is out of our control, if it is licensed under LGPL terms we're unable to change it

Reply to: unpack_thumb unpacks previews instead   7 months 2 weeks ago

many thnaks for the prompt response.
i'll try to test the parameter imgdata.sizes.raw_inset_crops[..].
best regards.

Reply to: unpack_thumb unpacks previews instead   7 months 2 weeks ago

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.

Pages