Sure - what I want is the 16 bit greyscale "raw" data so I can do my own de-bayer processing on it (except for the case of "full colour" raw files where I want the RGB image data). That's what the code that reads:

			if (!m_bColorRAW)
			{
				// Document mode (i.e. don't demosaic the image in libraw).
				O.no_interpolation = 1;
			};

was intended to achieve: m_bColorRaw is set thus:

		m_bColorRAW	= P1.is_foveon || !(P1.filters);

Would that be accomplished by grabbing the "raw image data" from libraw_raw_data after running unpack()?

If so I think (hope) I'll try using that based on the "unprocessed_raw.cpp sample.

Thanks again

OK I'm a bit disappointed about that. Looking at the source in dcraw_common.cpp it appears that the "document mode" stuff has been #ifdef-ed out of existence.

I had specified equivalent options to those I used with dcraw and captured the output file by sub-classing libraw and over-riding just dcraw_ppm_tiff_writer() and write_ppm_tiff() which worked a treat except that it didn't produce the 16 bit PGM greyscale data I hoped for but instead produced a 16 bit PPM RGB bitmap (which I confirmed using dcraw_emu).

Advice and guidance in more detail of how to get at the grayscale data will be greatly welcome

Might I ask why you explicitly disabled the "document mode" code?

Here's what my code looks like right now:

			if (!m_bColorRAW)
			{
				// Document mode (i.e. don't demosaic the image in libraw).
				O.no_interpolation = 1;
			};
 
			// Don't stretch or rotate raw pixels (equivalent to dcraw -j)
			O.use_fuji_rotate = 0;
 
			// Don't flip the image (equivalent to dcraw -t 0)
			O.user_flip = 0;
 
			// Output color space : raw-> sRGB (default)
			/*
			argv[argc] = _T("-o");
			argc++;
			argv[argc] = _T("0");
			argc++;*/
 
			workspace.GetValue(REGENTRY_BASEKEY_RAWSETTINGS, _T("BlackPointTo0"), bBlackPointTo0);
			if (bBlackPointTo0)
			{
				// Set black point to 0 
				O.user_black = 0;
			};
 
			// Output is 16 bits (equivalent of dcraw flag -4)
			O.gamm[0] = O.gamm[1] = O.no_auto_bright = 1;
			O.output_bps = 16;
 
			lstrcpy(g_szInputFileName, (LPCTSTR)m_strFileName);
			g_Progress = pProgress;
 
			if ((ret = rawProcessor.unpack()) != LIBRAW_SUCCESS)
			{
				bResult = FALSE;
				ZTRACE_RUNTIME("Cannot unpack %s: %s", m_strFileName, libraw_strerror(ret));
			}
			if (!bResult) break;
 
			if (LIBRAW_SUCCESS != (ret = rawProcessor.dcraw_process()))
			{
				ZTRACE_RUNTIME("Cannot do postprocessing on %s: %s", m_strFileName, libraw_strerror(ret));
				if (LIBRAW_FATAL_ERROR(ret))
					bResult = FALSE;
			}
			if (!bResult) break;
			pFiller = new BitMapFiller(pBitmap, pProgress);
			pFiller->SetWhiteBalance(fRedScale, fGreenScale, fBlueScale);
			// Get the Colour Filter Array type and set into the bitmap filler
			m_CFAType = GetCurrentCFAType();
			pFiller->SetCFAType(m_CFAType);
 
			// Set up the intercept code to write the image data to our bitmap instead of 
			// to an external file, and invoke the overridden dcraw_ppm_tiff_writer()
			rawProcessor.setBitMapFiller(pFiller);
			if (LIBRAW_SUCCESS != (ret = rawProcessor.dcraw_ppm_tiff_writer("")))
			{
				bResult = FALSE;
				ZTRACE_RUNTIME("Cannot write image data to bitmap %s", libraw_strerror(ret));
			}

Thanks

It would appear there's a possible bug with libraw in this area.

If I run dcraw -d M103_L_0048_ISO800_60s__16C.CR2, it creates a PGM output file:

29/05/2019 12:01 18,024,947 M103_L_0048_ISO800_60s__16C.pgm

if I run dcraw_emu -disinterp M103_L_0048_ISO800_60s__16C.CR2, it creates a PPM output file:

29/05/2019 12:02 54,074,807 M103_L_0048_ISO800_60s__16C.CR2.ppm

I see two problems:

1) This is the trivial issue that the output fileid is slightly different (which I'm happy to forgive).

2) The major problem is that the output file is NOT a single colour PGM greyscale bitmap as was produced by dcraw, but a 3 colour PPM bitmap.

Cheers

I guess the question I *should* ask is when is the approximate release date for the next version?

I know from experience designing and managing IC design projects you may not be able to give me even an approximate date for a variety of reasons. But if you can, I'd appreciate knowing. Thank you.

Most likely, this link will help: https://www.libraw.org/docs/API-CXX.html#memwrite

Dear Sir:

LibRaw's main goal is to extract raw data and metadata from RAW files, we're focused on it.
Postprocessing code (demosaic, etc) is derived from Dave Coffin's dcraw.c and we do not have any plans to improve it in LibRaw. We consider this postprocessing code as 'demo', or as 'quick and far-from-perfect way to implement some processing in other software'.

So, if you want to do something special, e.g. floating point processing, or better negative values handling, or something else, LibRaw provides full access to unaltered pixel values decoded from RAW. Sure, you'll need to implement demosaic and other postprocessing in your software.

ACES matrix is defined in void CLASS convert_to_rgb()
The resulting profile is automatically embedded in the output file if you use -o 6 Your bitmap image processing needs either to acknowledge the embedded profiles, or you can extract the profile from the output and assign it manually. The first solution is the right one.

There is no colour matrix embedded in CR2 files that we know of, and I doubt it is even there. Canon DPP software contains the profiles (mostly they are LUTs, not simple matrices).

Just checked with master branch from Github: I do not see any problems with file you provided.

Note: the file is compressed with lossy (JPEG) compression, one need to build LibRaw with USE_JPEG compile-time define to support this kind of DNGs

LibRaw is targeted to general purpose/mass market photographic cameras (see the list above), not special application ones.

However, it will decode any standard photographic raw file, so if some multispectral camera records DNG files, LibRaw will able to read it.

Most likely no.

We do not have raw files samples from this camera.

LibRaw::open_bayer() designed exactly for this

Look into samples/openbayer_sample.cpp for details.

When the Nikon z6 z7 release the firmware？