0

I am working on bayer raw(.raw format) image domain where I need to edit the pixels according to my needs(applying affine matrix) and save them back .raw format.so There are two sub-problems.

  1. I am able to edit pixels but can save them back as .raw I am using a robust library called rawpy that allows me to read pixel values as numpy array, while I try to save them back I am unable to persist the value

    rawImage = rawpy.imread('Filename.raw') // this gives a rawpy object

    rawData = rawImage.raw_image //this gives pixels as numpy array

    .

    .//some manipulations performed on rawData, still a numpy array

    .

    imageio.imsave('newRaw.raw', rawData)

This doesn't work, throws error unknown file type. Is there a way to save such files in .raw format.

Note: I have tried this as well:-

rawImageManipulated = rawImage

rawImageManipulated.raw_image[:] = rawData[:] //this copies the new data onto the rawpy object but does not save or persists the values assigned.

  1. Rotating a bayer image - I know rawpy does not handle this, nor does any other API or Library acc to my knowledge. The existing image rotation Apis of opencv and pillow alter the sub-pixels while rotating. How do I come to know? After a series of small rotations(say,30 degrees of rotation 12 times) when I get back to a 360 degree of rotation the sub-pixels are not the same when compared using a hex editor.

Are there any solutions to these issues? Am I going in the wrong direction? Could you please guide me on this. I am currently using python i am open to solutions in any language or stack. Thanks

Bimal Gupta
  • 71
  • 1
  • 3

1 Answers1

0

As far as I know, no library is able to rotate an image directly in the Bayer pattern format (if that's what you mean), for good reasons. Instead you need to convert to RGB, and back later. (If you try to process the Bayer pattern image as if it was just a grayscale bitmap, the result of rotation will be a disaster.)

Due to numerical issues, accumulating rotations spoils the image and you will never get the original after a full turn. To minimize the loss, perform all rotations from the original, with increasing angles.

  • How is this rotation of bayer raw image different from a RGB Image, there too could be numerical issues ? Say there is a rotation of 10 degrees, the rotation matrix would be same in both cases . the only difference i see is bayer is single channel (atleast initially) while RGB has 3 channels. – Bimal Gupta Aug 25 '20 at 11:32
  • @BimalGupta: this is because the color planes of a Bayer are interleaved and not independent. –  Aug 25 '20 at 12:13
  • What if I separate out the channels , apply rotation matrix to them individually and combine them post rotation? I know for sure the images I using are in Pattern of RGBG i.e, R(0,0), G(0,1),B(1,0),G(1,1) – Bimal Gupta Aug 25 '20 at 13:20
  • @BimalGupta: don't do that. Convert to RGB to rotate, then back to Bayer. –  Aug 25 '20 at 13:26
  • Actually that's the constraint , i am not allowed to convert to rgb via any post-processor whatsoever. I have tried that approach and it works but converting to RGB defeats my purpose. Everything should be done and handled on the bayer domain strictly no interpolation or demosiacing should be involved. I know I am asking too much from the community but my ultimate question is, is it possible ? – Bimal Gupta Aug 26 '20 at 04:29
  • Progress Update : I have applied rotation on separate channels , and the rotation is applied correctly( i think ) on individual channels. now the issue is with recombining the channels, i don't get a perfectly overlapping channels(actually its far from perfect). if I am able to recombine them perfectly then the issue of bayer rotation is resolved. – Bimal Gupta Aug 26 '20 at 04:32
  • Did you convert from Bayer to plain RGB ? –  Aug 26 '20 at 07:12
  • No i did not convert to rgb , i cannot convert to rgb that is the part of the problem – Bimal Gupta Aug 26 '20 at 10:01
  • @BimalGupta: why can't you ? I told you that the results would be a disaster. –  Aug 26 '20 at 10:04