[doompicdump] Batch image converter - new version 1.1

[bagheadspidey]

neither work properly.

grr, It looks like something has decided to put quotes around my strings.

@ window flashing madness: dammit. that cracks me up whenever you say it though

[bagheadspidey]

Ok! New version up, and this one works on windows, I promise =)

not tested on linux yet, but I have faith that it will work just fine.

Download - doompicdump-0.9.zip

All that's left to do is get imagemagick to save full color pngs on windows... this shouldn't be that hard, maybe another version of imagemagick would work properly? =/

[Enjay]

I promise =)

You are a man of your word. The entire sprite set for the Hexen serpent converted just fine using the default Cyan. The mage sprites converted just fine using the DeePsea background colour. Both of those were just done dumping the pngs into the main directory. A third test specifying a sub directory to put the sprites in also worked completely and as it was supposed to for a serpent conversion - creating a sub directory full of working sprites.

There was no window flickering madness and the progress bar worked nicely.

By George, I think he's got it.

One thing that might serve as an improvement if you want to tweak it further: in previous versions, when something failed (like imagemagick complaining about bad parameters) the error window flashed on and off so quickly it was very hard to read - and all the constant stealing of focus with a new window for every attempted run of imagemagick made it hard to interrupt the program to cancel it too. If you wanted to add a catch in there somehow so that if there was an error the conversion would pause to allow the user to read the error message, it might be helpful. Equally (fingers crossed) it may not be needed.

[bagheadspidey]

Thanks for you attention to this thing, Enjay =) some previous versions actually kept a log - I'm playing with the idea of putting it back in, but hopefully as you said it should not be needed, as hopefully nothing will go wrong and nobody will want to check it ;p

Right now I want to get the damn thing to save in true color mode... but first I think I need to get out of the house for a while

[Enjay]

Just to let you know - I used the converter quite a bit today, using graphics from Heretic, Hexen and Strife and then trying them out in Doom. Every conversion that I tried worked just as I wanted it to. I think it's reasonably safe to say that 0.9 reliably does what it is supposed to. Thank you very much for this converter. It's exactly what I needed.

[Ghastly]

Heh, I definately could've used this about two weeks ago, when I converted the 13 weapons in my mod from .wad to .pk3 XD.

[bagheadspidey]

New version available, several new features added. Please see first post for details.

suggestions, comments, complaints, etc. welcome =)

[Enjay]

OK, test results. First of all: the new interface layout - I prefer it. The program seemed to work nice and smoothly and I was not aware of any problems with the actual running of the program either. Most results were good, although some had limitations.


The following conversions were all done on a set of Hexen serpent graphics, exported with XWE as BMPs and then as lmps. 113 sprites in total (113 bmps 113 lmps).

Conversion at the defaults.
8 bit, translucency,
no compression.
Worked as expected in game.
size of output directory (113 pngs) 132,157bytes

As above, but true colour
Worked as expected
354,757 bytes

8 bit compressed
Worked as expected
129,562 bytes

true colour compressed
worked as expected
176,305 bytes

8 bit
no compression
scaled to 200%
fast rescale
worked in game, with a limitation
180,202 bytes
Limitation - offsets from the original lmps used so pngs would still have to manually corrected to sit high enough and centred. Fast resize to 200% is (as expected) a little blocky. Size reduction would be a different matter.

8 bit
no compression
scaled to 200%
bicubic rescale
transparency worked, but this was not a huge success
445,706 bytes
Problem (not too surprisingly) there was a nasty white border around the edge and various glitches on the image. This is clearly a bad combination of options - but I expected it to be. As with the previous resize, offsets were also an issue. Bicubic also made the image quite blurry.

---

true colour
no compression
scaled to 200%
bicubic rescale
worked with limitations
669,597 bytes
Limitations: in GZdoom, the edge of the graphic was translucent where, presumably, the colour and transparency had been averaged. Again, the image also looked blurry and this also made details, like the bright purple eyes of the serpent look quite dull. In Zdoom it looked a bit better because forcing it to the Doom palette and not using transluceny sharpened the image a bit - but this wasn't a huge success either. My guess is that size reduction would, again, be more successful. Not too surprisingly, offsets were still an issue.

Finally, I did a set of sprites that used a colour other than cyan as the background and these also worked.

Summary: All size retaining conversions worked quickly and gave the desired result in game.

Compression does reduce file sizes without any immediately obvious problems in game.

Resizing has limitations: bicubic looks bad when converting to an 8 bit image - no surprise. Fast versus bicubic is a matter of taste, target engine and whether scaling up or down is being done as to how desirable the results will be (as with and graphics resizing). Offsets for sprites are not very useful with a resize because the original offsets for the original size of graphic are used so some post production would still be required to make resized sprites sit correctly in game.

[bagheadspidey]

Hey, excellent, thanks Enjay! Here's a new version that fixes one of those problems (adjust offset when rescaling), and also adds a feature I thought might be useful to ReX - you can now use different source images besides bmp - on my system several formats including tga all worked fine =)

Enjay, I will definitely take the rest of your comments into consideration - the blurry edge thing can be resolved by allowing the user to set a "no partial transparency " option along with a cutoff point - any pixels more transparent than the cutoff point become fully transparent, and vice versa. It may still look crappy though. Also you have guessed downsampling big images is a lot neater than upsampling small images, and bicubic should be fine for that =)

Download - doompicdump-1.0b.zip

edit - whoa, that border is nasty. I'll work on the "no partial transparency" option.

[Enjay]

Scaling offsets seems to work nicely. Here's a bicubic and a fast 200% serpent.



They both have correct offsets, I just caught the serpent on a lower frame with the fast resize. You can see how blurry the bicubic is, and you can see the translucent border. I know that the blurryness is a function of what I was doing rather than a shortcoming of the tool though. The border thing you suggest sounds interesting. What would be even more interesting is if you could look at resizing using hq2x or hq4x filtering. Any chance of that?

http://www.hiend3d.com/hq2x.html

[bagheadspidey]

The problem with the hq2x / hq3x / hq4x filters is, as far as I can tell they totally ignore transparency information. So, they will blend the edges of the sprite with the background color and will throw out any alpha information.. also i did some tests and they don't really look all that great with the doom sprites imo - maybe something like lanczos3 would be better.

---

POSS.png

[skadoomer]

Wow, this saves me a ton of work. Thanks spidey!

offtopic: do png's work with color translations yet?

[Enjay]

The problem I've had with hq2x (etc) filers too has been the edges. I don't know if it can deal with transparency properly or not, but I couldn't get it to. The latest beta of EDGE is worth checking out to see hq2x filters in action in a game engine. I don't know how convinced I am about how well they work, but it is interesting.

http://edge.sourceforge.net/

[bagheadspidey]

New version up. See first post for details.

[Nash]

I'm probably dumb but there's something I just can't seem to grasp... and that is, 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.

I am not against this tool, but I just don't see how using this tool is better than using something else which I already have and use regularly. Perhaps I missed something... ?