for doing screenshots from the command line - use scrot

for doing screenshots from the command line - use scrot

[Alexander Stohr]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

scrot - this relatively old program should be a nice and handy alternative 
for doing screenshots on the command line on OE based system.

invoke it by "scrot" and get e.g. "2010-11-25-170400_1280x1024_scrot.png".
the offered set of options does look rather helpful for lots of common cases.

binary file size on x86 was 64k. there is in fact a set of librarys needed.
its giblib & Imlib2 & X11 & Xext & Xau & freetype plus few more basic ones.

see attachment for more info and the *.bb file.

regards, Alex.

-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

[-- Attachment #2: scrot.tar.bz2 --]
[-- Type: application/x-bzip, Size: 1919 bytes --]

Re: for doing screenshots from the command line - use scrot

[Marcin Juszkiewicz]

Dnia czwartek, 25 listopada 2010 o 17:39:04 Alexander Stohr napisał(a):
> scrot - this relatively old program should be a nice and handy alternative
> for doing screenshots on the command line on OE based system.
> 
> invoke it by "scrot" and get e.g. "2010-11-25-170400_1280x1024_scrot.png".
> the offered set of options does look rather helpful for lots of common
> cases.
> 
> binary file size on x86 was 64k. there is in fact a set of librarys needed.
> its giblib & Imlib2 & X11 & Xext & Xau & freetype plus few more basic ones.

Can you compare it with fbgrab? Less deps and same work done.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: for doing screenshots from the command line - use scrot

[Alexander Stohr]

Marcin Juszkiewicz wrote:
> Can you compare it with fbgrab? Less deps and same work done.

fbgrab has a file size of 35k on my x86 system. scrot has 64k.
(this would favor fbgrab.)

fbgrab depends on libs png12 & a few standard libs.
(this would favor fbgrab.)

fbgrab uses the framebuffer devices. scrot uses X11.
(this results in fbgrab getting some boot time fb ascii console contents
on my x86 box whilst scrot really captures the scree X11 manages.
this means fbgrab is a pretty local thing that wont work by principle
when your X11 is based upon a driver that does NOT utilize fb buffers.
this would favour scrot in terms of flexibility and compatibility.)

fbgrab allwos width/height specification. scrot allows window specific capture (using the mouse) and has an option for taking window borders - since its X11 aware.
(this would favor scrot in terms of flexibility.)

fbgrab works on a single framebuffer. scrot is multi head aware and can even join the grabbed images to a whole desktop image - since its X11 aware.
(this would favor scrot in terms of flexibility.)

fbgrab is very limited in bit depth. scrot man pages does not talk about any bit depth limitations.
(this would favor scrot in terms of flexibility.)

fbgrab supports PNG. scrot supports PNG.
(on par.)

fbgrab seems to have a fixed image quality. scrot takes a quality argument.
(this would favor scrot in terms of flexibility.)

fbgrab needs an external utility for time stamping. scrot has it built in.
(time precision should be more accurate for scrot.
scripted execution time is somehwat lower with scrot.
this would favor scrot.)

fbgrab allows reading in sort of unformatted files. scrot allows imrpoved scripting using special wildcards and can pass these to a second application, e.g. a file system based hirarchical storage.
(this would favor scrot in terms of flexibility.)

fgrab stores the data as it is. scrot has a built in thumb nail option.
(this would favor scrot in terms of flexibility.)


my personal rationale why scrot is a good option to offer:

- the built in time stamping is very handy.
- the usage of X11 infrastructure makes it a different in functionality and thus working
-- in cases where X11 is not based upon fbdev
-- and for cases with alternate bit depths.
 (you probably want screenshots to work, not to be urged to first "fix" an incompletly implemented utility.)
- the compression ratio is flexible.
- there are low-effort paths for file processing and storage automation.


side note:
if its only about freezing fbdev contents for e.g. inspection with a hexadezimal view, then sometimes a simple "cat /dev/fb0 >freezed.raw" will do the job. clipping and compressing the result using a few stand alone applications might be a post processing path.
-- 
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl