I'm not sure why you were cryptic about whether my description of what I should do is right, but anyway I tried it and it seems about right, see https://i.imgur.com/gidxryK.png (mine seems to have slightly brighter highlights compared with the rest of the picture, maybe my normalisation is better. I didn't have to do anything after the matrix multiplication btw, I guess the matrix is normalised). I also don't understand why you talk so much about normalisation given that it wasn't relevant to my problem, I didn't have to change anything about normalisation at all, knowing the correct order of operations and knowing to clip (and when) was what was crucial.

I didn't look at sample code, maybe I should have, I just didn't think of doing that because I'd expect such examples to show how to call functions, not how to replicate them, which is what I'm trying to do in my own mostly GPGPU-based way. Instead I debugged through libraw_dcraw_process() to see what it does, and let's just say that it's rather difficult to learn anything doing that given that the 21,420 lines of code in draw_common.cpp are hardly self-documenting, not to mention there are some things with which even the debugger is lost, like accessing the elements of variables (in libraw_cxx.cpp) such as O. or C. or S..

I don't blame you guys for the lack of explanatory comments in the source since I know dcraw was the same way, but while it's good that you documented the API, I think that libraw, as the main successor of dcraw, deserves more because it's so important, your work will outlive you, it's the go-to thing for processing images from any camera, and when we're all dead of old age digital archaeologists will be looking into whatever succeeds libraw to know how to decipher ancient digital photographs, not just how to use it because even now the way it does things shows its age. And so the problems I'm facing they will face too unless the people who understand the code document what it does. Just look at a function like recover_highlights(), I'm sure it does something quite good, but how would anyone know what it does? It doesn't have a single comment explaining what's going on, how is anyone supposed to maintain that? Look at it https://github.com/LibRaw/LibRaw/blob/master/internal/dcraw_common.cpp#L... and see how much you need to use your memory to remember what's the purpose of each of the blocks of loops. Even I am not fond of adding comments, but for blocks of code I'll put a small comment that says what the block of code below does, it just makes everything seem instantly clearer and less daunting.

Let's say someone (e.g. me) thinks "libraw is good, but I want to do most of the processing in floating-point arithmetic in real time OpenCL. I don't want to do original research into every aspect of processing, I just want to do what dcraw/libraw does for every phase of processing", then I need to understand what the code does, not just how to use it. I looked into a couple of the better demosaicing algorithms that libraw provides and it seems like there's literally nothing about at least one of these anywhere on the Internet. Some of them have a few comments, but only in Russian! All we have is the code itself and little to help us understand what it does let alone why it does it. I don't mean to criticise you guys, I really appreciate your hard work and how you guys answer all our questions, we'd have a much harder time without your help, I'm just saying that ideally you should write down what you understand about the code as comments while you still remember what it does. As it is the inner workings of libraw could hardly be more arcane.