Imagine bytes in memory for an RGB image--R and G and B represented by bytes in sequence. If an image is NxM then the memory layout will be M repetitions for vertical scanlines of 3*N bytes in sequence for the horizontal pixels. (As one might expect.)
A mandate has come down from on high that you need to be able to isolate contiguous color planes. You might be asked for the R, G, or B plane. When you give back the plane it must be the N*M bytes in sequence for that color.
Yet there is a twist: You cannot use additional memory proportional to the size of the image. Thus you must shuffle the bytes somewhere inside of the existing RGB data to provide the contiguous plane for the requested color. And you must be able to recover the original image when processing of that color plane is finished.
The image size is actually not relevant to the problem as it operates on the buffer as a whole. Input is bytes (expressed as hexadecimal ASCII) followed by which plane to extract:
Output is the extracted color plane, then the original input *(also in hexadecimal ASCII):
Where you shuffle the memory is up to you. But you must actually shuffle the data to produce contiguous bytes (requiring the client to use an iterator is cheating). And you must be able to reverse the operation to restore the original information.
Lowest big-O implementation wins. Between two implementations with equal big-O performance... winner decided by code golf rules.