Recent comments

Reply to: CR3 to Tiff conversion results in different brightness levels   3 days 5 hours ago

Brightness adjustement and maximum level adjustement are different things (wrong maximum may/will result into 'pink highlights' problem and auto-adjust works against it).

I agree, set_maximum_adj_threshold should be added to C-API.

Reply to: CR3 to Tiff conversion results in different brightness levels   3 days 5 hours ago

Hi Alex,

with dcraw_emu using -M -o 0 -c 0 -j -W -q 1 -4 -T as arguments, both TIFF images converted from CR3 now look equally bright, and the two TIFF images converted from the corresponding DNG files also look equally bright. However, the TIFF images converted from CR3 and DNG differ in brightness. Is this by design?

I'm now trying to figure out how to use it programmatically. The parameter adjust_maximum_thr seems not to be accessible from the libraw_set_... API. I'm using C# with InteropServices. I think I can write such method and amend it to libraw; or better maybe you should consider the addition of this method (something like libraw_set_maximum_threshold).

I already used in my program:

```
libraw_set_no_auto_bright(handler, 1);
libraw_set_bright(handler, 1.0f);

```
so I expected no automatic brightness adjustment anyway.

Thanks, LelliD

Reply to: CR3 to Tiff conversion results in different brightness levels   3 days 12 hours ago

(copied from E-mail, probably this answer may be interested to public)

To turn off automated maximum adjustement use dcraw_emu -c 0 (imgdata.params.adjust_maximum_thr = 0)

Reply to: CR3 to Tiff conversion results in different brightness levels   6 days 5 hours ago

We never publish files that are sent to us without explicit permission.

Please use any file sharing service (e.g. WeTransfer/free option) and send the link to info@libraw.org

Reply to: CR3 to Tiff conversion results in different brightness levels   6 days 5 hours ago

Hi,

I can provide the files (as long as they will not appear in a public forum). I think it would suffice to upload the two .CR3 files (35 MB each). Can you please show me a way to upload them?

Lellid

Reply to: libraw.dll?   6 days 8 hours ago

We do not provide precompiled snapshot versions. Please contact vendor of your software to re-compile it with newer libraw.

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

Looks like your patch works like a charm.

Cheers,

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

Yes (if you do not use earlier github snapshots)

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

No problem: no risk no fun ;).
I will let you know.

Last question. Which version I could consider for your change?

LIBRAW_VERSION > LIBRAW_MAKE_VERSION(0, 21, 0) ?

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

As a result, you use very untested (and not supported) code path :)

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

I will test it.

In fact our code is cross-compiled with CI pipelines: can't use visual studio. Especially because we build it for linux too.

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

Followup:
I do not have msys2/mingw/similar tools installed, so not tested.

MS Visual Studio (community) is free, so it makes sense to use native vendor compiler for Win32

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

Oh thank you.

If you fix it, you'll make me happy.
Thanks for your feedback

Please, let me know.
Cheers,

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

OK, this need to be fixed.

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days ago

OK thanks for your kindness.
But with libraw_open_wfile

I get:

undefined reference to `libraw_open_wfile'

because in the LibRaw code there is

#if defined(_WIN32) && !defined(__MINGW32__) && defined(_MSC_VER) &&           \
    (_MSC_VER > 1310)
  int libraw_open_wfile(libraw_data_t *lr, const wchar_t *file)
  {
    if (!lr)
      return EINVAL;
    LibRaw *ip = (LibRaw *)lr->parent_class;
    return ip->open_file(file);
  }

So it can't work under msys2.

Reply to: Different behaviour between git and 0.20.2 with wide char   1 week 2 days 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   1 week 2 days 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   1 week 2 days 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   1 week 2 days 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   1 week 2 days 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   1 week 2 days 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   1 week 2 days 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   1 week 4 days ago

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

Pages