Geek Answers Handbook

What format does "adb screencap / sdcard / screenshot.raw" create? (without the "-p" flag)

I am using adb screencap utility without the -p flag. I assumed that the output would be unloaded in a raw format, but not like it. My attempts to open a raw image file using the Pillow library (python) resulted in:

 $ adb pull /sdcard/screenshot.raw screenshot.raw $ python >>> from PIL import Image >>> Image.open('screenshot.raw') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/....../lib/python2.7/site-packages/PIL/Image.py", line 2025, in open raise IOError("cannot identify image file") IOError: cannot identify image file

I did not find the right way to read raw images like this, I even took the following shot: How to read a raw image using PIL?

 >>> with open('screenshot.raw', 'rb') as f: ... d = f.read() ... >>> from PIL import Image >>> Image.frombuffer('RGB', len(d), d) __main__:1: RuntimeWarning: the frombuffer defaults may change in a future release; for portability, change the call to read: frombuffer(mode, size, data, 'raw', mode, 0, 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/..../lib/python2.7/site-packages/PIL/Image.py", line 1896, in frombuffer return frombytes(mode, size, data, decoder_name, args) File "/Users/..../lib/python2.7/site-packages/PIL/Image.py", line 1821, in frombytes im = new(mode, size) File "/Users/..../lib/python2.7/site-packages/PIL/Image.py", line 1787, in new return Image()._new(core.fill(mode, size, color)) TypeError: must be 2-item sequence, not int

All possible mode parameters result in the same TypeError exception.

Here's what the hexdump utility hexdump :

 $ hexdump -C img.raw | head 00000000 d0 02 00 00 00 05 00 00 01 00 00 00 1e 1e 1e ff |................| 00000010 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff |................| * 000038c0 1e 1e 1e ff 1e 1e 1e ff 21 21 21 ff 2b 2b 2b ff |........!!!.+++.| 000038d0 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff |................| * 00004400 1e 1e 1e ff 1e 1e 1e ff 47 47 47 ff 65 65 65 ff |........GGG.eee.| 00004410 20 20 20 ff 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff | .............| 00004420 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff 1e 1e 1e ff |................| *

In osx:

 $ file screenshot.raw screenshot.raw: data

screencap man page doesn’t reveal much about the output format without -p :

 $ adb shell screencap -h usage: screencap [-hp] [FILENAME] -h: this message -p: save the file as a png. If FILENAME ends with .png it will be saved as a png. If FILENAME is not given, the results will be printed to stdout.
+6
source share
2 answers

Thanks to extracting your file, I think your raw file is formed as a width x height, and then the whole set of RGBA pixels (32 bits) (width x height times) Here I see that you got a captured image of 720x1280.

Let the ImageMagick toolkit help you view / convert it to a more suitable file format. Below is a sample that might help you (ImageMagick convert command, for osx see http://cactuslab.com/imagemagick/ )

 # skip header info dd if=screenshot.raw of=screenshot.rgba skip=12 bs=1 # convert rgba to png convert -size 720x1280 -depth 8 screenshot.rgba screenshot.png

If this does not work, you can try changing skip = 12 to skip = 8 and / or 720x1280 to 1280x720 ..

Hope that helps

+3
source

Format:

  • 4 bytes as uint32 - width
  • 4 bytes as uint32 - height
  • 4 bytes as uint32 - pixel format
  • ( width * heigth * bytespp ) bytes as a byte array - image data , where bytespp are bytes per pixel and depend on the pixel format . Usually bytespp is 4.

Information from screencap source code .

In your example:

 00000000 d0 02 00 00 00 05 00 00 01 00 00 00 1e 1e 1e ff
  • d0 02 00 00 - width - uint32 0x000002d0 = 720
  • 00 05 00 00 - height - uint32 0x00000500 = 1280
  • 01 00 00 00 - pixel format - uint32 0x00000001 = 1 = PixelFormat.RGBA_8888 => bytespp = 4 => RGBA
  • 1e 1e 1e ff - data of the first pixel - R = 0x1e; G = 0x1e; B = 0x1e; A = 0xff; R = 0x1e; G = 0x1e; B = 0x1e; A = 0xff;

Pixels with data stored in a byte array of size 720 * 1280 * 4.

+7
source

More articles:


All Articles