Recent comments

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

You may switch back via defining LIBRAW_USE_DEPRECATED_IOSTREAMS_DATASTREAM

But this is temp. solution: it will work with LibRaw 0.21, but will be removed in future releases.

Also: LIBRAW_WIN32_UNICODEPATHS is set if:
# elif _GLIBCXX_HAVE__WFOPEN && _GLIBCXX_USE_WCHAR_T

So if such macros are defined for your runtime, unicode paths should work.

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

There is libraw_open_wfile() that expects wchar_t filename.

LibRaw/github switched from iostreams-based LibRaw_abstract_datastream implementation to native-calls based implementation (LibRaw_bigfile_buffered_datastream) which is much faster under Win32.

Probably, your msys2's std::filebuf worked right with UTF-8 filenames, but this is miracle, not the expected behaviour.

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

Here my code

static int siril_libraw_open_file(libraw_data_t* rawdata, const char *name) {
/* libraw_open_wfile is not defined for all windows compilers */
#if defined(_WIN32) && !defined(__MINGW32__) && defined(_MSC_VER) && (_MSC_VER > 1310)
	wchar_t *wname;
 
	wname = g_utf8_to_utf16(name, -1, NULL, NULL, NULL);
	if (wname == NULL) {
		return 1;
	}
 
	int ret = libraw_open_wfile(rawdata, wname);
	g_free(wname);
	return ret;
#elif defined(_WIN32)
	gchar *localefilename = g_win32_locale_filename_from_utf8(name);
	int ret = libraw_open_file(rawdata, localefilename);
	g_free(localefilename);
	return ret;
#else
	return(libraw_open_file(rawdata, name));
#endif
}

As you can see I use it when it is allowed. But on my side I always compile with msys2... So I don't have API.

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

Hummm If I well recall, LibRaw::open_file(wchar_t*) does not work with msys2.

And my code is compiled through msys2.

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

It looks like (I'm not sure, but the function names indicate this), you're converting filename from UTF-8 back to UTF-8.

If it worked at 0.20 then it was a miracle.

LibRaw has special LibRaw::open_file(wchar_t*) call under Win32, it is THE recommended way to go.

I do not know why UTF-8 filenames worked before. It should not.

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

Ok Sorry if I'm unclear.

My question is:

is there a difference between 0.20.2 and git version for the wide char handling ?

Because if I compile my soft with LibRaw <= 0.20.2 I have no problem. If I compile with LibRaw git version I have an error trying to opening CR2 Raw with wide char in paths.

My code was not very useful I must admit, this is just my code used to read wide char path.

Reply to: Different behaviour between git and 0.20.2 with wide char   2 years 2 months ago

Could you please reformulate your question? What is the problem and how it is related to code you quote?

Reply to: CR3 to Tiff conversion results in different brightness levels   2 years 2 months ago

It is very difficult to discuss the problem in abstract without having sample files

Reply to: libraw/dcraw_emu crushes shadows and turns them blue compared to dcraw with exact same settings   2 years 3 months ago

It is hard to discuss anything related to RAW processing without having the sample file(s)

Reply to: Unable to read RAW image from Agfa Photo DC-833m sensor   2 years 3 months ago

Thank you for the files, downloaded.

These files are uncompressed 16-bit sensor dumps (for example, 3264*2448 = 7990272 pixels x 2 bytes per pixel = 15980544 bytes, exact size of file provided).
Also, according to manual (easy to find), camera does not provide raw recording, so raw files are some kind on debug mode or something like that.

I'm unable to see any meaningful image in these samples, it looks like flat field shot, or something like that. So it is not possible to determine if white/black level set correctly or not. Please provide something with well known subject.

Sensor dumps are supported via pre-defined table of known file sizes, to enable half-size image support apply this patch:
diff --git a/src/metadata/identify.cpp b/src/metadata/identify.cpp
index 251f97b2..eab078c0 100644
--- a/src/metadata/identify.cpp
+++ b/src/metadata/identify.cpp
@@ -247,7 +247,8 @@ void LibRaw::identify()
{ 10134608, 2588, 1958, 0, 0, 0, 0, 9, 0x94, 0, 0, "AVT", "F-510C" },
{ 10134620, 2588, 1958, 0, 0, 0, 0, 9, 0x94, 0, 0, "AVT", "F-510C", 12 },
{ 16157136, 3272, 2469, 0, 0, 0, 0, 9, 0x94, 0, 0, "AVT", "F-810C" },
- { 15980544, 3264, 2448, 0, 0, 0, 0, 8, 0x61, 0, 1, "AgfaPhoto", "DC-833m" },
+ { 3995136, 1632, 1224, 0, 0, 0, 0, 8, 0x61, 0, 1, "AgfaPhoto", "DC-833m" },
+ { 15980544, 3264, 2448, 0, 0, 0, 0, 8, 0x61, 0, 1, "AgfaPhoto", "DC-833m" },
{ 9631728, 2532, 1902, 0, 0, 0, 0, 96, 0x61, 0, 0, "Alcatel", "5035D" },
{ 31850496, 4608, 3456, 0, 0, 0, 0, 0, 0x94, 0, 0, "GITUP", "GIT2 4:3" },
{ 23887872, 4608, 2592, 0, 0, 0, 0, 0, 0x94, 0, 0, "GITUP", "GIT2 16:9" },

Or use 'custom camera API'

Reply to: Unable to read RAW image from Agfa Photo DC-833m sensor   2 years 3 months ago

Hi Alex,
I have fixed the link permissions. Sorry about that.

https://drive.google.com/drive/folders/1X1Tdy744XXb2AaMvE9ZIwsNRqjoYbFUe....

The files are quite large and sometimes these email filters block files. Do let me know if you still have trouble accessing the files.

Regards,
Dinesh

Reply to: Unable to read RAW image from Agfa Photo DC-833m sensor   2 years 3 months ago

Unfortunately, the link you provided is not for everyone, I've requested access

Alternatively you can attach the samples to E-mail targeted to info@libraw.org

Reply to: Is the COLOR function exposed in the C API?   2 years 3 months ago

Nevermind, of course, is is prefixed, I don't know why I didn't see it: libraw_COLOR Sorry for the noise!

Reply to: Sony ilce 7rm3a Support to be added   2 years 3 months ago

7r iii A is supported in the recent snapshot

Reply to: Pixel data manipulation   2 years 3 months ago

Unaltered ('as unpacked') pixel values are stored in imgdata.rawdata array(s)

samples/unprocessed_raw.cpp example writes (unaltered) data to TIFF file, probably this is code example you're looking for

Reply to: LibRaw 0.20 supported cameras   2 years 3 months ago

ilce 7rm3a - sony alpha 7r iiia is actually Almosen same like ilce 7rm3 - sony alpha 7r iii

Reply to: iPhone 11 Halide DNG gives black image.   2 years 3 months ago

Btw, there is zero guarantee that in a DNG that ColorMatrix2 corresponds to D65 illuminant, or that there is one corresponding to a D65 illuminant at all. It is just a recommendation, not a requirement.

Reply to: iPhone 11 Halide DNG gives black image.   2 years 3 months ago

Not sure it is good idea (unless specified explicitly by library user via some flag?)
cam_xyz contains built-in data (from colordata.cpp), dng_color filled by DNG tags, not sure DNG data should always overwrite built-in data.

Reply to: imgdata.sizes.raw_pitch is only available after unpacking?   2 years 3 months ago

Yes, raw_pitch field is filled only on unpack() phase: this data field describes layout of data in imgdata.rawdata.* array(s), not in input file and it is not known before unpack().

Reply to: iPhone 11 Halide DNG gives black image.   2 years 3 months ago

Thank you. I looked in to this more, it turns out the libraw->rawdata.color.cam_xyz field is blank with DNG images. I had to look at libraw->rawdata.color.dng_color

Sorry about the mistaken post!

I have a suggestion: Maybe put DNG's ColorMatrix2 (Daylight) in to the cam_xyz field? It might reduce confusion for some developers.

I am using build from latest source code from github.

Reply to: How to compute White Balance from cam_mul?   2 years 4 months ago

In colour science CCT is derived from xy. xy calculation depends on the colour transform, raw to XYZ. This transform is not one-to-one because raw data isn't colorimetric. Different companies use different colour transforms for the same camera model. Say, the camera and ACR report different CTs for the same shot.
Your best bet is to shoot a camera at each CT setting, compile a table of CTs vs. wb coeffs, and interpolate.

Reply to: How to compute White Balance from cam_mul?   2 years 4 months ago

What I want to do is to give user a Color temperature slider that needs to start with the color temp of the photo (say 5000K) and let him move in the range of say 2000-10000K.

So how do I compute this using the various data obtained in libraw_colordata_t? I thought cam_mul is a start?

Reply to: How to compute White Balance from cam_mul?   2 years 4 months ago

White balance is not measured in Kelvins.

Reply to: How to enable multiple processors support for macOS?   2 years 4 months ago

There is no omp.h file in standard toolchain

Pages