White balance 16-bit TIFF

Hello. We have an OpenCV script working to white balance 8-bit imagery based on a fixed light source used to illuminate an X-Rite chip chart, this light in turn used for a specialized form of volumetric capture. Since we use the same light and do our photogrammetric scanning in dark conditions, the values driving white balance based on the chip chart can be applied globally.

Alas, testing against control images the script falls apart when applied to 16-bit TIFFs. I’m not a programmer, am the end user working with others who produced the script, which I happily make available here if that’s helpful. Thanks.

please, do so . . . . . !

Thanks, awaiting the code from my colleague.

1 Like

there are some special functions in OpenCV that can’t operate on 16 bit data. OpenCV can perform reading, writing, and various arithmetic on 16 bit images/data.

MRE required. we can’t do your debugging for you if you can’t give us a program to debug. don’t forget the traceback or error message.

Thanks to you both. I received the script that works on 8-bit, also the one that doesn’t work with 16-bit, but now reading about MRE, I’m thinking I need my support to step in and try to comply with the “M” for minimal. He has sample files and a control group to compare against, will show up here soon. I’ll let him clarify the particulars of the operations being run, am hopeful either of you will be able to determine whether these fall inside the supported arithmetic with OpenCV. Again, many thanks.

it doesn’t have to be a minimal or reproducible MRE but there’s got to be some “meat on the table”. it’s always best if the one with the issue can present specifics like an API call that throws an error or a concrete “data situation”.

in the meantime, maybe you can explain,
why the shift to 16bit tiff happened ?

what’s in the data ? why does it need 16bit images now ?
would a simple conversion already do the trick ?

also, we have a mcc module for macbeth charts here , have a look

Sure, so why 16-bit. My capture system provides for diffuse/specular separation via cross-polarized and co-polarized imagery. Each pair is co-registered, allowing us to tease out isolated specular information (roughness) from color (albedo). The roughness property of a material conveys many things about surface properties, but presently we’re focused on the high and highest frequency geometry, which we commonly know as texture. We use that information to drive a bump map, converts to a normal map, same info drives roughness maps in a shader tree. While we’d prefer to work in RAW, 16-bit TIFF comes in second place preserving the fine gradations that 3D software downstream will read as scalar. Here’s an example of the technology comparing my system to common photogrammetry: https://sherpacart.net/demo-cave-clouds/


Hello Berak and crackwitz, apologies for the following. You both have graciously offered to help, and frankly I disagree with my partners about their concern about publicly sharing our code, at least at this highly preliminary stage. The volumetric capture system I described in providing you context for what’s driving our need for 16-bit does involve protected IP, so I do respect my partner’s point, but I personally see no downside sharing something so basic as the ability to control WB or white point in 16-bit via OpenCV when the benefit of receiving your expertise for free gets us down the road.

That said, might either of you be interested in working offline freelancing and under NDA? And if so, thanks for emailing me benjy.vc@gmail.com with CV. Many thanks for your understanding.

1 Like

If anyone can help you in detail without seeing techical details, approah help can be given.

It is obviously possibly to step the code in a debugger with an image that works and one that doesn’t. Then you’ll see the first function that fails.

Then you can ask help about just that one function, or try to find another way to fo what it does, replace it with something from another library, etc…

After that, tackle the next failure…

I would be fundamentally open to freelancing. I’ve only done that nationally (Germany) so I know enough of the red tape so our tax office doesn’t send me nasty letters that’d make me want to jump out a high window. I don’t know the red tape required for invoices in the EU or even to the USA. if I didn’t have to worry about that, I’d be game. oh also my CV, being “red tape”, is a mess, and nobody who ever looked at it gave me feedback.

I am a little worried that you guys don’t feel safe presenting even a toy example. there’s nothing innocuous about a couple lines of code that

  • imread some tiff/png, or whip up some synthetic data like np.arange(2**16, dtype=np.uint16).reshape((256,256))
  • do some dummy arithmetic like add 42 to everything, or simple Gray World stuff and maybe gamma mapping
  • write back out with imwrite or whatever

Vielen Dank, crackwitz, I hear you and agree, this is truly innocuous, don’t blame you feeling worried. Again, if it were me alone, I wouldn’t be wasting your time posting a question only to question your offer answer my questions. Alas, I’m needing to remain accountable to my partners, one of whom is also an investor, and they both have clamped down on sharing publicly. I find it silly, if not also counter productive, but that’s just me.

I’ll pass it on that you’re open to freelancing, keeping it on up and up it’s simple to wire into business accounts, don’t know the threshold in Germany, but here anything paid out, domestic or international, under $800 does not require submitting form 1040. Again, thanks and bitte verzeihung.