[doompicdump] Batch image converter - new version 1.1

[BilboHicks]

Hi,
I have a question, since I'm not 100% following what exactly this utility is capable of.

After saving a bunch of sprites from (say) Strife wad using (say) SlumpEd, this tool will allow me to batch convert them to pngs that can be used with GZDoom/Zdoom (with offsets) ? This utility supports conversion to the Doom palette then? No need to use GIMP to do it? (I havent figured out how to get GIMP to batch process files either.)

If so, then I will definitely be using this app

[bagheadspidey]

...how is using this tool better than what SLumpEd can already do?

In SLumpEd, you can open a WAD that has LMP graphics, select them and convert to PNG and it'll do it really quickly, and preserve the LMP's offsets and transparency... ?

The advantages are subtle. For one thing, slumped doesn't want to compile on linux very easily (someone PLEASE prove me wrong), so it's good for people who are using linux to have something that actually works. Enjay mentioned that slumped occasionally makes pixels transparent that shouldn't be during export. Also, you get a bit more control over the output images with this tool, and the compressed pngs it produces with pngcrush are very small.

Another possible use: Dump a set of images and lumps from a stock sprite as a base for spriting work. You can either modify the bitmaps you exported, or use this conversion tool, delete the bitmaps and modify the resultant pngs. Most (all?) image editors will remove the offset info from the png as soon as you modify it - but you can just run this tool again and quickly put all of the offsets back in. If the source bitmap is gone but the lump is still present, the offsets will be set in the target png without its appearance being changed. So, there's kind of a cool side effect from storing the offsets separately.

Another use: batch image conversion in general (to png, at least). This thing will convert just about any format to png. ReX used it (correct me if I'm wrong) to convert a bunch of targa images (captures of 3d models I believe) to png format. In his case he was going for small filesize, so he might have for example scaled all of the images to something like 75% of their original size (afaik slumped cannot do this) and used the "compress" option.

...
1 - After saving a bunch of sprites from (say) Strife wad using (say) SlumpEd, this tool will allow me to batch convert them to pngs that can be used with GZDoom/Zdoom (with offsets) ?

2 - This utility supports conversion to the Doom palette then?

1 - Yes. The catch is, you have to export them from (SlumpEd) twice - both as images and as "raw" lumps (should have lmp extension). This tool gets the image data from the image and the offset data from the lump. I may add the ability to read offset data from pngs later.
2 - No, but that's a good suggestion and I'll probably add the ability to force a particular palette now that you mention it. Of course, this is not necessary for gzdoom as it is not limited to any specific palette, and zdoom does it's best to map png images into the doom palette anyway... I don't know, I'll think about this. Maybe we could use this tool - http://fordy.planetunreal.gamespy.com/bright.htm

[BilboHicks]

Thanks for the info!
Sounds like it is shaping up to be a very cool tool.
I'll check out that other link too. I'll also play around with gimp, and see if it has any utilities written for it for batch processing.

[Nash]

Thanks for your explanation, Spidey. Yes, you raise some important points that I missed...

[Enjay]

This seems a reasonable place to post a further request that is kind of related:

Would it be possible to make something that can interrogate the dimensions of an existing png, then calculate typical offsets for it and then apply them to the graphic? ie, no lmps with pre-defined offsets would be involved. This would be for giving offsets to new pngs that have not been part of a WAD at any point.

To try and clarify what I'm talking about:

Most sprites in Doom have an X offset of half their width and a Y offset if slightly less than their height. Setting these manually can be a real pain if you have made a lot of PNG sprites. So, if the tool could interrogate a png, discover that it was, say, 32 wide and 64 tall, it would give it offsets of 16 and 60. Obviously this wouldn't be perfect for everything, but DeePsea does something similar for regular sprites and its certainly a good starting point for most sprites.

I have noticed that if a width is an odd number, rounding down the offset, rather than rounding up, tends to give a slightly better result. I guess it must just be the way most sprites are drawn, but it's not a big deal.

Further refinements that would be nice:

Optionally having the tool set the Y offset at the full height rather than slightly under (in the above example, offsets of 16, 64 would be used). This is useful for GZdoom because it gets around the whole floor clipping and sprite shifting issue. I once spent about an hour and a half shifting thousands of sprites up by about 4 pixels.

A second option for setting offsets as "projectiles" rather than regular "standing on the floor" sprites. Projectiles typically have offsets close to half their width and half their height.

HUD weapon sprite offsets would also be nice but, frankly, they vary so much in their position on the screen that coming up with a "good starting point" is much harder (DeePsea tries, but I've never found it particularly useful for weapon sprites). Weapons are also far less likely to have the 60 or more sprite graphics of a typical monster so it's less of an issue anyway.

Again, being able to specify a transparent colour would also be useful if the graphics haven't already been saved with transparency.

[bagheadspidey]

That's definitely a reasonable request. I wrote a little script to do almost exactly what you are talking about... it takes a folder full of pngs, setting the origin point to the center of the base of the images.

Code: Select all

#~/bin/bash
#
# grabfeet
#
# * Uses SetPNG to set the origin point to the bottom center of the image.

#path to SetPNG.exe. I renamed mine setpng and stuck it in /usr/bin (obviously)
export setpng="/usr/bin/setpng"

#set grab at feet
for p in *.png; do
        export geometry=`identify -verbose $p | grep Geometry`
        export height=`echo $geometry | sed -r 's/.*x//'`
        export center=$((`echo $geometry | sed -r 's/.*\s(.*)x.*/\1/'` / 2))
        echo "Setting grAb chunk for $p ($center,$height)"
        $setpng -grab $center $height $p $p
done

I use it a lot; I can cd into a folder of sprites and type "grabfeet" and all of the offsets are set very quickly. Unfortunately windows' command shell sucks, and doesn't give you nearly the functionality you need to use a simple shell script like this.

I can add this feature to this tool if you need to use it right away, but I won't create a new tool for this. I am currently working on a project similar to DeuTex, which will eventually have a graphical front-end. I am hoping to incorporate all of the editing tools I have written so far into the front-end, and also use it as a base for features like the one you suggest. Until then, I probably won't be creating any more stand-alone tools unless there is a real need for something...

[wildweasel]

That's something that could come in handy for me as well.

[Enjay]

I can add this feature to this tool if you need to use it right away, but I won't create a new tool for this.

That would be great. I only ever envisaged it as an extention to the existing tool anyway. No great rush, but it is something I use a lot in DeePSea for non-png sprites so it would certainly get used as and when it became available. Your deutex modernisation sounds interesting too.

[Theshooter7]

I'd hate to mega-bump this, but...

I can't seem to for the life of me get this to work right. I exported all of my BMPs and raw LMPs as per the instructions, but when I use the tool to convert the images, I get an error stating the PNGs weren't found (an error returned from setpng). My guess is they aren't being converted. What gives?

[bagheadspidey]

Ew, who knows? This thing is wacky. I guess I should update it to use grabpng instead of hijacking Randy's setpng...

Why don't you give unwad a try? It can convert a whole wad full of images to png all at once without exporting them first.

If the wad you are extracting from has a PLAYPAL, unwad will use it. So the absolute simplest way to do this is:
- take the PLAYPAL from doom2.wad (or whatever iwad) and stick it in your wad (at the beginning, before any images).
- drag your wad onto unwad.exe
- an extracted copy of your wad should appear in the same directory as your wad, with all images, sounds, etc ripped out.

If you are ok with using the command line, there's a bunch of stuff you can do with it... You can tell unwad to use the extracted palette without having to add it to your wad. Also try adding -g 3 and it will sort the sprites into neat folders for you. Run unwad with no arguments to dump help.




edit - thinking about this more, this is the sort of thing that happens when your computer decides you aren't allowed to use your temp directory, which seems to happen to a handful of windows users for no apparent reason. I'm guessing you can test it by trying to create a file in the temp directory and see if you're allowed. If not, maybe there's a way you can elevate your permission or something, I don't know. Seems to me a temp dir should be writable by any user, but maybe MS has other ideas. If anyone can shed some light on this, I'm all ears.

[Gez]

If you can't write to the temp directory, log in as an administrator, right-click on the temp directory, Properties -> Security tab, and change the permissions from there. Make sure to give "total control" to all usergroups that seem like they should have total control, such as identified users.