Thank you Alex for your answer. I tried with open_bayer as I think the raw file has no metadata. With the code bellow I could see that readb as 1280000 values instead of 640000 for an image 800x8000. The final result with dcraw_process is not satisfactory. I wonder If and how I could retrieve the unpacked values and do the conversion myself.

FILE *in = fopen(fname, "rb");
	fseek(in, 0, SEEK_END);
	unsigned fsz = ftell(in);
	unsigned char *buffer = (unsigned char *)malloc(fsz);
	if (!buffer)
		return 2;
	fseek(in, 0, SEEK_SET);
	unsigned readb = fread(buffer, 1, fsz, in);
	if (readb != fsz)
		return 3;
	std::cout << "readb" << readb << std::endl;
	LibRaw rp;
	rp.imgdata.params.output_tiff = 1;
	int ret = rp.open_bayer(buffer, fsz, 800, 800, 0, 0, 0, 0, 0,
							LIBRAW_OPENBAYER_BGGR, 0, 0, 0);
	if (ret != LIBRAW_SUCCESS)
		return 4;
	if ((ret = rp.unpack()) != LIBRAW_SUCCESS)
		printf("Unpack error: %d\n", ret);
 
	if ((ret = rp.dcraw_process()) != LIBRAW_SUCCESS)
		printf("Processing error: %d\n", ret);
 
	char outfn[256];
	sprintf(outfn, "%s.tif", fname);
	if (LIBRAW_SUCCESS != (ret = rp.dcraw_ppm_tiff_writer(outfn)))
		printf("Cannot write %s: %s\n", outfn, libraw_strerror(ret));
	else
		printf("Created %s\n", outfn);
 
	ret = rp.dcraw_process();
	// Check for error using LIBRAW_SUCCESS. I never get an error here
 
	ret = rp.dcraw_ppm_tiff_writer(fname); 

Microsoft RAW extension is produced by Microsoft, we're not involved in this process in any way (Microsoft uses the public version of LibRaw).
So, we're completely not responsible for MS RAW Extension.

You may try to use our FastRawViewer instead.

So you're talking about Microsoft RAW Extension, right?

What software (that uses LibRaw for RAW support) do you use?

There is separate project on github: https://github.com/LibRaw/LibRaw-cmake

Note: we (LibRaw team) is not responsible for it and do not provide any support for it.

Sony ILCE-1 is fully supported in 202110 snapshot:
Supported camera list: https://www.libraw.org/supported-cameras-libraw-202110
Announce page: https://www.libraw.org/news/libraw-202110-snapshot

OK, understood.
DNG file metatata:
| | 1) ImageWidth = 3040
| | 2) ImageHeight = 2014
| | 21) DefaultCropOrigin = 15 7 (15/1 7/1)
| | 22) DefaultCropSize = 3008 2000 (3008/1 2000/1)
| | 27) ActiveArea = 0 0 2014 3040

By default, LibRaw extracts ActiveArea image (3040x2014)

Suppose we are discussing the latest public version (https://github.com/LibRaw/LibRaw, master branch):
DefaultCrop tags are parsed into imgdata.sizes.raw_inset_crops[0]
This crop can be applied via: LibRaw::adjust_to_raw_inset_crop(1)

BUT:
DefaultCrop top/left in this specific file is odd and will be rounded to nearest even margin, so image will be cropped to 3007x1999 starting at 16,8

There is no way to avoid this in current LibRaw (this change was implemented in LibRaw 0.20)

You may switch to LibRaw pre-0.20 (0.19 or so) with LIBRAW_PROCESSING_USE_DNG_DEFAULT_CROP flag set to params.raw_processing_options

Could you please provide some sample file?

Greetings, everyone. I have fond memories of this project and the learning involved. But I also have emails coming in requesting permission to view my tables with their expired links. For every person that requests access, Google tells me

"_____@whatever.com is requesting access to a file via an old link, which is no longer valid due to a security update. Share the file with this person directly, or copy and send the new link in sharing settings."

The email from my original account was shut down years ago, but I hosted the files on a permanent account. So here are updated links for each of the resources. Here's to another four years of, hopefully, helping people out.

Also @ajohnson was very, very correct about the DHT artifacts in dark regions. Spent a whole what, day?, half a day?, in 2019, cross-examining the algorithms and the rest of the project and unfortunately it was all DHT!

Fence / Roof comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svVXd6MVEzN0pUajQ/view?usp=sh...

Light comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svQlAwMlZubFJvelk/view?usp=sh...

Cone comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svR2NETGNocWRwUkk/view?usp=sh...

Track line comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svb1ROZXlmWGdTbUE/view?usp=sh...

Black / white checker comparison (animated GIF!):
https://drive.google.com/file/d/0ByFHxc7qU-svUHBPZjUycUxhOGM/view?usp=sh...

Summary table with performance times (on a decently large 16bit image):
https://drive.google.com/file/d/0ByFHxc7qU-svRkVhWGdYTnlOdE0/view?usp=sh...

Hi kmilos,

Using MingW was what I did before, but was wondering if I could get things to work using Cygwin.

With MingW on Windows I am having serious character encoding issues since the new Libraw versions related to :

https://www.libraw.org/node/2692

and thus

https://github.com/LibRaw/LibRaw/commit/30595a731f3bea78f0410426b73ef3af...

I was able now to turn on unicode in MingW using: https://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/

Needed to alter libraw.h and now I can use wchar_t but still not working with asian characters...

So still trying. Do you have any suggestions how to make it work with MingW and wchar_t file path?

See also the patches Cygwin itself used to carry for LibRaw 0.18, (they're probably out of date since codebase was significantly changed since), but swab is also mentioned: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libraw.git...

According to quick googling, swab function is present in cygwin C runtime.

Sorry, do not have cygwin installed, so no additional help (e.g. what include file should be added)