[doompicdump] Batch image converter - new version 1.1

[bagheadspidey]

Notice:

this tool is now part of DoomCrap.

__________________________________

UPDATES!

Made a few useful changes so I figured I'd make an update...

New stuff:

- Alpha cutoff controls let you disable partial transparency
- Real-time preview of image as it will look after conversion takes place. Switch this off using the eyeball button.
- Program guesses whether to use a transparency mask and what color it should be when you view a new sprite. If you don't want this to happen, hit the lock button.
- added a button to view previous image in folder.

Screenshot-DoomPicDump Batch Image Converter.png

---

DoomPicDump - a doom-friendly batch image converter.

This tool is used to batch convert doom format images to PNG format
while preserving the image's origin offsets.

For now, you will need to use a tool like XWE or Slumped to export the
images before they can be processed by this tool.

SIMPLE INSTRUCTIONS

- Run XWE and load up a WAD

- Highlight all image files you want to dump.

- Click "Entry -> Save As" and save them somewhere. They should save
as bitmaps.

- Click "Entry -> View Raw Data"

- Highlight all image files you want to preserve offsets for.

- Click "Entry -> Save As" and save them where you saved the bitmaps.
They should save as "lmp" files.

- Run this tool and point it at the folder with all that stuff in it.
The rest should go smoothly

Download


feedback welcome, as always.

[Csonicgo]

Keep making things. please.

[Enjay]

Yay! and yet Nooo!

OK, I extracted a bunch of files as BMPs and then the same bunch as LMPs. The proggy looked in the directory, told me how many files of each type there were and I pressed convert. Command windows opened and closed in a flash and a few minutes later (there were lots of files) it said it had worked. I did notice, as the windows were flashing by that there was some kind of message about "too many files" towards the end of the conversion but the windows went so quickly that I couldn't read them properly. It looked like it might have been a message from Randy's "setpng" program - is that part of the process? Anyway, on a quick browse with Paint Shop Pro, there was 1 png per bmp so I thought, "fine proceed to the next stage". I put the pngs into a WAD and checked them with XWE. XWE didn't display them and said they had an offset of 0,0. I loaded the wad up into Zdoom and there were a bunch of error messages at startup. When I summoned an enemy that used some of the sprites - it was invisible.

I tried again with a much smaller sample - the Iron Lich from Heretic. Again the windows flashed by. Again there were error messages. This time I noticed that these seemed to come after the conversion to pngs had already happened. I stuck the files in a WAD. Again, XWE could see the lumps, knew how big the graphics were but didn't display them and said their offsets were 0,0. On loading Zdoom I got this:

---

Code: Select all

Invalid data encountered for texture LICHA1
Invalid data encountered for texture LICHA2A8
Invalid data encountered for texture LICHA3A7
Invalid data encountered for texture LICHA4A6
Invalid data encountered for texture LICHA5
Invalid data encountered for texture LICHB1
Invalid data encountered for texture LICHB2B8
Invalid data encountered for texture LICHB3B7
Invalid data encountered for texture LICHB4B6
Invalid data encountered for texture LICHB5
Invalid data encountered for texture LICHC0
Invalid data encountered for texture LICHD0
Invalid data encountered for texture LICHE0
Invalid data encountered for texture LICHF0
Invalid data encountered for texture LICHG0
Invalid data encountered for texture LICHH0
Invalid data encountered for texture LICHI0

Looking at the pngs produced, they are not paletised but "true colour" which may explain some of the problem.

[bagheadspidey]

New version up - doompicdump-0.3.zip

Some bugs fixed, some may remain? Still need help testing this =)


edit: instructions - sorry you will have to switch to linux before you can use this piece of shat tool

[bagheadspidey]

new version - doompicdump-0.4

need windows testers. I think the problem with running in windows lies with ImageMagick, so in this version you can experiment with your own arguments and try to get it to work. Here's the imagemagick arguments reference.

The default setting work fine for me on linux. Again, the latest version hasn't been tested on windows... yet

[Enjay]

OK, this has taken me a little while of trying and retrying different things and this seems to do the job.



I'll now see if putting any of the command line options that you had specified by default back makes any obvious improvements. However, setting it up like this seems to reliably give me pngs that are 8 bit and with a transparent background.

[bagheadspidey]

let me try your arguments, the stuff i included was not necessary except to make the images paletted... it was more of an example that worked. It worked fine with that box blank on my system too. The pngs are usually smaller as full color, so it would be best if we could have at least the option of making full color pngs.Does your command work without the -depth 8? Maybe -type TrueColorMatte works for you also (without depth 8? maybe with depth 24)?

edit - the -density 72x72 is so the Gimp doesn't bitch about converting to a default resolution. I guess it's worth keeping if it doesn't break anything...

also, does it still flash a bunch of cmd windows?

and, your settings work fine for me also... I could just make them the defaults and get rid of that bar... but i'd still like to have full color images if possible. Well, if you (or anyone else) feels like playing around with it some more and can get it to make full color pngs under windows that load in zdoom, i can just hard code those two options and make a check box... might be a little more user-friendly

[Enjay]

The important option seems to be -type PaletteMatte. I can't actually check just now but I'm sure that having that and nothing else produced true colour images that worked. By it's name, I would have thought that it would have reduced things to 8 bit but, like I said, I's sure that it didn't.

[edit]

Forgot to mention that it is still CMD window flashing madness.

and whilst I remember to check...

-density 72x72 does not seem to adversely affect Zdoom

However, I was wrong about -depth 8. Removing it does produce true colour images, but Zdoom can't use the images it produces

[/edit]

[bagheadspidey]

ok, for me -type PaletteMatte by itself produces useable 8 bit pngs =/

-type TrueColorMatte (by itself) produces usable rgb images. If that works for you, we can use that for true color and -type PaletteMatte -depth 8 for indexed.

heheh, i dont know wtf to do about those command windows... probably some option you can compile wxlua with would turn that off...

edit - typo

[Enjay]

Sorry, -type TrueColorMatte produces true colour pngs that PSP can read, but Zdoom can't read them.

[bagheadspidey]

updated. Many windows bugs should be fixed. doompicdump-0.6.zip

[Enjay]

OK, feedback:

It appears to run far more smoothly and the multiple windows have gone. The downside to that is that it doesn't look like it is doing anything and I only had my blind faith in Spidey's talents that it hadn't hung somehow. It's not such a big deal with maybe only a single monster where it appears inactive for only a few seconds, but when I converted a couple of thousand sprites in one go, it took almost 10 minutes whilst looking like it wasn't doing anything.

Other problems: One time it created an output directory, apparently flew through the conversion very rapidly, but the output directory was empty. The same source files had previously created a flawless conversion.

Twice it has not converted some sprites from a set. eg, when converting the Hexen serpent sprites, one time it converted SSPTM1, SSPTM2M8 and SSPTM3M7 but not SSPTM4M6 or SSPTM5. All other sprites in the set worked. Another time it converted only M1 and created a file called SSPTM (no extension) which actually turned out to be a PNG of the SSPTM2M8 sprite. No other rotations for that sprite and frame were converted. At other times, the full set worked. With 0.4, I was able to convert hundreds of sprites and none got missed or renamed at all to my knowledge.

So, summing up of 0.6... It looks and feels a bit neater, but function-wise it doesn't see so reliable.

[bagheadspidey]

Does this help?

doompicdump-0.7.zip

[bagheadspidey]

Does this help?

doompicdump-0.7.zip

bump - doompicdump-0.8.zip

which one works better on windows? If you can't tell a difference the second one is better

[Enjay]

Right, sorry I didn't notice these 2 new versions coming online. I have to say that it is hard to pick which one works best because neither work properly.

0.7 looks nice and the progress bar seems to work well enough but when I came to check the results, there were no pngs to be seen anywhere. I even did a search of my HD to try and track them down - nowt!

0.8 gave me the clues that it wasn't working a bit earlier on. The reason being that I thought Window flashing madness had returned. However, the process paused briefly, but long enough for me to read what the window was saying. It was an error message from convert.exe saying something like "invalid parameter Cyan" So, I tried exporting a bunch of sprites from DeePsea (which does not use cyan as the background colour) and set the image converter to use the appropriate background colour that DeePsea uses with Hexen (178, 17, 222). This time the error message was "invalid parameter rgb(178,". When I went into the directory to see if anything had been produced anyway, there were no pngs.