grabpng - now with 15% more grab

[bagheadspidey]

View latest changes

Keyboard Shortcuts:

Code: Select all

    Ctrl-S      Save current image
    Z           Previous image in directory
    X           Next image in directory
    L           Lock / unlock guides
    Tab         Select next control
    Arrows      Select controls
    Space       Activate selected control
    Esc         Quit program

Batch operations

Basically this is setpng on crack. It can do batch operations and the grab x and y position can be mathematical expressions including variables for the width and height of the image (so to set a grab point in the center of a bunch of images, you could do -grab w/2 h/2.) See the readme for more details.

Downloads & Info

Get the program (for windows or linux*), view the readme or browse the source.

*linux users should install fltk 1.1 libraries

---

Code: Select all

  Usage: grabpng [[options] <file1> [file2] [...]]

  Installation:
  
    Put grabpng anywhere you like. Make a shortcut to it on your
    desktop or in your programs menu. If you want to use grabpng
    in batch mode, you'll want to add it's location to your PATH
    environment variable.
  
    If you are not sure what your PATH environment variable is, 
    but you still want to use grabpng in batch mode, just put it
    in C:\Windows\System32.
    
  Overview:
  
    If you installed grabpng correctly you can click the icon or
    type "grabpng" at the command line to use the visual editor.
    
    If you are using grabpng from the command line you have
    powerful batch options available to you:

  Options:
                    
    -grab <x> <y>     Set contents of grAb chunk in files.
    -alph             Create alPh chunk in files.
    -noalph           Remove alPh chunk from files.

  Notes:

    The <x> and <y> grab values can be expressions.
    
    Variables allowed in expressions are:
      w - image width
      h - image height
      
    Constants allowed in expressions are:
      W - 320
      H - 200
      
  Keyboard Shortcuts:

    Ctrl-S    Save current image
    Z         Load previous image in directory
    X         Load next image in directory
    Tab       Select next control
    Arrows    Select controls
    Space     Activate selected control
    Esc       Quit program

  Examples:

    # Load the visual editor.
    
    grabpng

    # Load mymonster.png in the visual editor.
    
    grabpng mymonster.png

    # Grab two pngs at their centers and set alPh chunks.
    
    grabpng -grab w/2 h/2 -alph mydecal.png mydecal2.png

    # Grab all pngs in the current directory at their horizontal 
    # center, 4 pixels from the bottom of the image.
    
    grabpng -grab w/2 h-4 *.png

[Hirogen2]

Something is flakey:

Code: Select all

cygwin$ ./grabpng.exe -x w/2 -h y-9 wall74.png
Grabbing rtwall74.png [64x64] at (0,0).

linux$ ./grabpng -x w/2 -h y-9 wall74.png
Nothing to do.
grabpng -grab <x> <y> filename
 Set grAb chunk in png file.

0,0? Nothing to do?

[Graf Zahl]

570kb for such a small tool? iostream must be even worse with MinGW than with VC++...

[bagheadspidey]

Hirogen: there is no -x and -y, just -grab (just like in setpng).. so ./grabpng -grab w/2 h-9 wall74.png

Also, you might want to re-download it, that looks like output from a couple of versions ago.

Graf: I'm not sure why the windows exe is so big... the linux binary is much smaller. I have a feeling if it was compiled on windows it would not be so big... I'm not using iostream at all this time =/

[Hirogen2]

570kb for such a small tool? iostream must be even worse with MinGW than with VC++...

Cygwin ships g++ 3.x (mingw too?), and the 3.x series had a particularly bad libstdc++ (cout was also magnitudes slower than printf—this particular item has been fixed in 4.x).
I see that there are humongous symbols in `nm grabpng.exe` ... something related to libstdc++ too, whatever this "_emergency_buffer" thing of 16KB is...

Also, you might want to re-download it, that looks like output from a couple of versions ago.

Right...

[bagheadspidey]

Just to clarify, I've never actually built this from windows... I just built the windows executable from linux. So I don't think it's an issue with an old gcc or anything. Anyway, it's only half a meg in size, hopefully not too ridiculously huge by today's standards, but I'd like to look into it more. Can anyone confirm whether the windows binary actually works as intended, though?

Also, you might want to re-download it, that looks like output from a couple of versions ago.

Right... ;-)

No, really, it does. See that tiny bit of help it displayed? You know, the text that shows you how to use the command? ;p Now it displays a huge logo and a decent sized help screen =)

[Enjay]

Quick test under WinXP I was able to set offsets by specifying my own explicit values at the command line and by getting grabpng to set them based on the formula w/2 h. Both tests worked as expected. I don't have time for a more extensive test ATM, but those results are promising anyway.

[bagheadspidey]

Thanks, Enjay, you are my testing hero =)

I'm not sure if the windows command prompt interprets matching patterns in file names or if it is up to the program to do that, so something like grabpng -grab 0 0 *.png will work in linux (*.png is expanded by the shell) but maybe not in windows. That's the only thing I can think of that may not work if everything else looks good. Thanks for your help =)

[Enjay]

This worked:

Code: Select all

grabpng -grab w/2 h-4 *.png

0.png [64x128]
Grabbing at (32,124)

1.png [64x128]
Grabbing at (32,124)

2.png [64x128]
Grabbing at (32,124)

4.png [64x128]
Grabbing at (32,124)

5.png [32x64]
Grabbing at (16,60).

6.png [32x64]
Grabbing at (16,60).

7.png [32x64]
Grabbing at (16,60).

8.png [128x64]
Grabbing at (64,60).

9.png [128x64]
Grabbing at (64,60).

Double checked with XWE and all graphics were offset correctly.

[bagheadspidey]

Awesome, thanks for your time. I feel fairly confident about adding this to the wiki now.

[Graf Zahl]

Graf: I'm not sure why the windows exe is so big... the linux binary is much smaller. I have a feeling if it was compiled on windows it would not be so big... I'm not using iostream at all this time =/

I can tell you the reason:

Linux links the entire CRT dynamically, including the iostream stuff. The Windows version links the entire iostream module plus the incredibly bloated exception handling module into the executable.

Large binaries when using C++ seem to be normal for MinGW. ZDoom compiled with it is 1.5 times larger than the MSVC version.

I think a MSVC build will be smaller.

[bagheadspidey]

Graf: Thanks for that explanation. I suspected something like that was probably going on. I looked into it a little bit, but I think there's not much I can do on this end (I don't have a copy of msvc). I guess anybody that wants a small copy badly enough can compile it themselves, though ;p

[Hirogen2]

See that tiny bit of help it displayed? You know, the text that shows you how to use the command? ;p Now it displays a huge logo and a decent sized help screen =)

Yes; I did update and then It Worked™. Though, the fact that filecharset does not support an -o option makes for a broken out-of-src build with autotools.

The Windows version links the entire iostream module plus the incredibly bloated exception handling module into the executable.

And the reason for this is that there is no libstdc++ dll, but just the static archive

I'm not sure if the windows command prompt interprets matching patterns in file names or if it is up to the program to do that,

Windows does not give that sort of help. I would not bother with it anyway since grabpng is usually used to set some coordinates, rather than zero it; and coords for sprites are often different, depending on sprite.

[bagheadspidey]

See that tiny bit of help it displayed? You know, the text that shows you how to use the command? ;p Now it displays a huge logo and a decent sized help screen =)

Yes; I did update and then It Worked™. Though, the fact that filecharset does not support an -o option makes for a broken out-of-src build with autotools.

That -o option is a gcc option, not a filechars option. This isn't meant to work with autotools. Just run the build.sh script and everything should build. You might want to comment out the cross-compiling stuff first if you don't have those tools.

I'm not sure if the windows command prompt interprets matching patterns in file names or if it is up to the program to do that,

Windows does not give that sort of help. I would not bother with it anyway since grabpng is usually used to set some coordinates, rather than zero it; and coords for sprites are often different, depending on sprite.

I thought so too, but look at Enjay's post a few comments back. Now I'm confused. Can anyone clarify whether cmd.exe expands matching patterns? I saw another topic about this here somewhere but now I can't find it.

About coords being different depending on the sprite, that's what the expression evaluation is there for. I just ran this on a huge folder of ripped monster sprites using w/2 h-4 and in less than a second all of the grab points were in place. I only had to manually adjust the grab position on two frames (changed y value a bit on corpse frames) =)

[Hirogen2]

Precondition (cl=MSVC6):

Code: Select all

bash$ cat test.c
#include <stdio.h>

int main(int argc, const char **argv)
{
        printf("You gave me %d lousy args.\n", argc);
        return 0;
}

bash$ gcc test.c -o tcyg
bash$ cl test.c

Time of truth:

Code: Select all

cmd.exe> test.exe *.*
You gave me 2 lousy args.

cmd.exe> tcyg.exe *.*
You gave my 14 lousy args.

So cmd.exe does nothing, and it is the Cygwin runtime that expands the wildcards if you ran the program from outside a cygwin environment.