Recent comments

Reply to: Building, shipping libraw on macos Big Sur   2 years 10 months ago

make -f Makefile.dist
should do the trick

Reply to: DNG recorder   2 years 10 months ago

LibRaw is not about RAW writing, but about reading.

Reply to: Canon AFInfoData mismatch with ExifTool parsed result   2 years 11 months ago

ok, I get it.

Reply to: Canon AFInfoData mismatch with ExifTool parsed result   2 years 11 months ago

LibRaw is NOT a complete EXIF/Makernotes parser. We're focused on data that needed for RAW processing, other fields are optional. Please use some other software for complete metadata parsing and interpretation

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

Thanks for your reply and advice.

I've solved the panasonic rw2 issue.

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

1)Not sure what is displayed by exiftool, it may be offset from file beginning, not from jpeg preview start.
(hard to tell without having the file)

2) tags larger than 4 bytes contains offset (relative to IFD start), not exact value, so one need to seek to this offset to read the data. There is not enough output in your quote to check this.

BTW, I suggest you to not invent the wheel :), but use some exif parser (e.g. exiv2 if you can tolerate GPL licensing)

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

Hi, sorry to bother you again.

  | 9)  ExifOffset (SubDirectory) -->
  |     - Tag 0x8769 (4 bytes, int32u[1]):
  |         008a: ae 02 00 00                                     [....]
  | + [ExifIFD directory with 42 entries]
  | | 0)  ExposureTime = 0.002 (10/5000)
  | |     - Tag 0x829a (8 bytes, rational64u[1]):
  | |         04c4: 0a 00 00 00 88 13 00 00                         [........]

Don't know how the offset works,

0x008a + 4 + 0x02ae does not equal to 0x04c4
Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

Thanks for the tip. I'm trying to parse and get the data from lr_ptr->imgdata.thumbnail.thumb

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

I used the exiftool program to see the structure (with -v3 command line key to see details)
It clearly shows this:

| 32) JpgFromRaw (SubDirectory) -->
| - Tag 0x002e (713278 bytes, undef[713278]):
[skip[
--- DOC1:JpgFromRaw --------------------------------------------------------
JPEG APP1 (50684 bytes):
0006: 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 10 00 [Exif..II*.......]
[skip]
ExifByteOrder = II
+ [IFD0 directory with 16 entries]
and 0x004d is within Makernotes pointed by this (JpgFromRaw) EXIF

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

Great, I didn't know that the 0x004d tag is not in Raw exif but in thumbnail exif. Thanks for the advice.

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

I do not know what specific camera you're talking about.

Just inspected some GH5S file. For this file 0x004d/AFPointPosition tag is not in IFD0, but in makernotes section of EXIF.

The bad thing: this is NOT RAW/EXIF, but EXIF contained in embedded JPEG preview.

So, to extract the data you need:
- extract thumbnail (preview) using LibRaw::unpack_thumb
- use some EXIF parser to parse thumbnail's EXIF

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

I've tried to use these code to catch the exif tag data.

void exif_cb(void *context, int tag, int type,
			 int len, unsigned int ord, void *ifp,
			 INT64 base)
{
	print(tag);
	if (tag == (0x004d | 0x30000)) {
		print("get the 0x004d tag");
	}
}

0x004d is from https://exiftool.org/TagNames/Panasonic.html named "AFPointPosition".

I can get all the tags printed, but no "0x004d" found.

p.s.
The rw2 raw file i'm using can be extracted a "0x004d" AFPointPosition tag data by the ExifTool downloaded from https://exiftool.org/

Reply to: Panny Lumix GH5 II RAW   2 years 11 months ago

in the next public snapshot (this Fall)

Reply to: Read exif issue from panasonic raw file   2 years 11 months ago

You may try to use 'exif callback': https://www.libraw.org/docs/API-CXX.html#exif

Note: for panasonic's main IFD, tag is or-ed with 0x30000 (to distinguish from normal tiff ifd)

Reply to: Windows & LCMS   2 years 11 months ago

Could you please point out how you made it work with VS?
I have also compiled Libraw with enabled LCMS (by modifying Makefile.msvc file) and the generated executables work just fine supporting LCMS. However, not when I link Libraw to my VS. It still seems like it doesn't support LCMS. any advice?

Reply to: Phase One IIQ decoding   2 years 11 months ago

According to your code, you use 'all defaults' for libraw processing (dcraw_process), so daylight white balance and automatic 1%-ETTR brightness correction.

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

There's other huge gamuts too, like xTremeRGB , MaxRGB, and AllColorsRGB. None of these are in libraw, but the description of xtremeRGB says that, "CAUTION: XtremeRGB may cause hallucinations or eye cancer." (http://www.hutchcolor.com/profiles.html)

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

I realize that, just thinking out loud pragmatically 😉

I guess there are ProPhoto and Rec2020 outputs available to cover a "similar" range and precision...

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

LibRaw is limited to whatever raw data is. Processing of raw data (white balance, colour space conversion, gamma) is out of the scope of main LibRaw functionality, we keep such processing for testing purposes only. LibRaw is not a raw converter and isn't meant to be one ;)

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

Btw, I'm wondering how useful (or harmful?) is it to have that huge ACES AP0 output color space when LibRaw is limited to uint16 representation...

Sounds like an AP1-based ACEScg D65 adapted option would be good to have as well?

One should perhaps clarify in the docs that AP0 based "ACES2065-1 adapted to D65" is meant by the existing "ACES" enum?

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

> My apologies if I offended or annoyed you.
Not in the least.

> I was under the mistaken impression that the ICC profiles are simply assigned on output
They are not, but even if they were, what good is it to assign one profile while converting to a different one?

I checked, and yes, Coffin's aces_rgb matrix isn't adapted to D65.

Fixed in master now (the changes are in src/tables/colorconst.cpp) https://github.com/LibRaw/LibRaw/commit/1974214acf47ef260853d74006765746...

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

My apologies if I offended or annoyed you. I was under the mistaken impression that the ICC profiles are simply assigned on output

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

I think I made it clear what I'm referring to, and so did you. We can't fix what is not there. Your proposal is technically impossible (and in any case, the starting point is the matrix in the standard), and I explained what we are going to do. Let's return to the topic only when there will be anything new to discuss.

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

To which matrices are you referring? The cam2rgb matrices? I am talking about what's in the actual icc profiles embedded in the images, to be clear.

Reply to: I think the ACES color profile in libraw is incorrect   3 years 2 weeks ago

I'm saying that matrices in Coffin's workflow are of a different nature (his workflow doesn't use "forward matrix for ACES", or "ACES colour profile", so no place to change it), and that we will check aces_rgb matrix to see if the chromatic adaptation from ACES "D60-like" white point to D65 necessary for Coffin's workflow is missing.

Pages