It sounds like you don't know where your problem is:
you might have incorrect register settings, or just register settings that aren't suitable for your use-case
you might have a bug in your interface driver, which appears to be bit-banging with GPIO rather than a hardware camera interface
you might be doing everything right with the camera but are your image processing algorithm doesn't have the results you want.
You have said that you suspect (1) but have posted code to suggest you might want help with (2). Personally I think (3) is most likely.
I suspect this because just taking the MSB of the Y channel and discarding everything is a very naive process and I would not usually expect this to work. Effectively you are thresholding at 50%. What makes you think 50% is the correct threshold? Maybe you need to not throw all that data away and do some more context aware image processing like using a different threshold in different parts of the image, or maybe you need a further step after thresholding, such as morphological operations.
I would approach the problem like this: get all the data out of your interface driver and look at it as a full colour image. If it looks ok as a photo, then probably (1) and (2) are good and you need to think about (3).
If the image is corrupt then you need to decide between (1) and (2). To do this I would first set the register values back to the default values straight from the manufacturer. If this fixes it the problem was (1), if it is still corrupt then (2).
Obviously this isn't a full solution to the problem, but you need to narrow it down before you dive deep.
Almost as an aside, one quick thing springs to mind is are those discontinuous blocks separated at a fixed spacing? It looks like maybe 8 pixels? If the problem is (1) then YUV422 breaks the image into blocks and discards the chroma data. Maybe YUV444 or even RGB would give better results. If the problem is (2) then a fixed block size like that might mean you are assembling your bits into bytes incorrectly.