• All, Gmail is currently rejecting messages from my host. I have a ticket in process, but it may take some time to resolve. Until further notice, do NOT use Gmail for your accounts. You will be unable to receive confirmations and two factor messages to login.
Resource icon

PalApply v2 2.0.3

No permission to download

Plombo

OpenBOR Developer
Staff member
Hey everyone. I rewrote my 10 year old program PalApply to support alpha masks and write well-optimized PNG output. I quietly released a replacement for the command line PalApply a year or two ago, but now I've gotten around to a full replacement for the GUI version that most people use.

Differences from the original PalApply, copied from the PalApply v2 readme:
  • If the source image has non-trivial alpha (partial transparency), then in addition to the usual indexed image, PalApply v2 will save a corresponding alpha mask that can be used with OpenBOR's alphamask command.
  • If the source image has any transparency at all, fully transparent pixels will be mapped to the transparent color (the first color in the palette).
  • The palette must be specified using an image file; there is no longer support for palettes in .pal/.act/.gpl format.
  • [since v2.0.1] The palette must be an image in PNG or GIF format or a palette in .act format; there is no longer support for palettes in .pal/.gpl format.
  • All output is in PNG format. GIF, PCX, and BMP are still supported as input formats, just not for output.
  • As a tradeoff for the above, the PNGs written by PalApply v2 are compressed to a small file size and optimized for fast loading. This is in sharp contrast to the poorly encoded PNGs written by the original PalApply, which were often larger than the equivalent GIFs.
  • The user interface of PalApply v2 is similar to that of its predecessor, but is more polished in various ways.
  • PalApply v2 is written in C rather than Java, so it doesn't require the Java runtime to be installed.

Everything else is about the same as the old PalApply; the interface is prettier but works the same. The only potentially contentious change is PalApply v2's inability to write GIF output. The only reason to use GIF over PNG is that GIFs load a bit faster, but the next release of OpenBOR will have my rewritten PNG decoder. With that, the optimized PNGs written by PalApply v2 load slightly faster than their GIF equivalents, so there will no longer be any reason to use GIF. If, in spite of all that, you still really want GIF output for whatever reason, you can still just use the original PalApply. It's not going anywhere.

With all that said, you can download PalApply v2 at the GitHub releases page. It supports Windows and Linux, but for Linux you'll have to compile it yourself.

I'm not aware of any issues with it, but it hasn't been tested as much as the original PalApply, so let me know if you find any issues.

Enjoy! ;D
 
So are normal PNG's different from the ones outputted from PalApply v2 or will all PNG's load faster ?
 
All .png will load faster. That was a separate issue with OpenBOR .png decoder that caused some people to cling to .gif despite the advantages of .png format.

The palette must be specified using an image file; there is no longer support for palettes in .pal/.act/.gpl format.
All output is in PNG format. GIF, PCX, and BMP are still supported as input formats, just not for output.

Awww... OpenBOR supports .act files for palettes, and so I don't bother with palette images any more. Was there a specific reason why Plombo? No big, just curious. I just started using PalApply a couple of weeks ago and it's a fantastic time saver. This look even better!

DC
 
Damon Caskey said:
Awww... OpenBOR supports .act files for palettes, and so I don't bother with palette images any more. Was there a specific reason why Plombo? No big, just curious. I just started using PalApply a couple of weeks ago and it's a fantastic time saver. This look even better!
DC

I didn't realize modern, 32-bit OpenBOR still supported .act for anything. I can add it in the next version easily enough; it's a simple format.
 
.act is the only way to add alterate pallets for levels. Just for consistency with that, I added them for model pallets last year.

It also helps a bit for folks coming over from Mugen or really just about anything else. They're also tiny files and one less extra step to compared to using images as palettes.

Really just better in every way IMO.

DC
 
Question about .act files: are they always 768 bytes, or can they be smaller for palettes of less than 256 colors?
 
I've never seen anything other than 768B. It would have to be for some esoteric platform like EGA or proprietary console format. Gif and 8bit png are always 8bit minimum no matter how many colors you actually use.

DC
 
Damon Caskey said:
I've never seen anything other than 768B. It would have to be for some esoteric platform like EGA or proprietary console format. Gif and 8bit png are always 8bit minimum no matter how many colors you actually use.

GIF and PNG support palettes that have less than 256 colors and leave the later slots unused, even as every pixel still takes 8 bits. I was asking if ACT supported something like that, but according to this, it looks like it doesn't and ACT files are always 768 bytes.
 
Plombo said:
GIF and PNG support palettes that have less than 256 colors and leave the later slots unused, even as every pixel still takes 8 bits.

Sorry, misunderstood you. I know they support few colors, but the bit size doesn't change and I thought that's what you were asking. Guess it doesn't matter anyway. :)

DC
 
Okay, PalApply v2.0.1 is now out with support for palettes in .act format. See the post at the top of this thread for how to download it. :)

It doesn't seem like anyone's actually tried using PalApply v2 yet. Anyone who does, please post in this thread and let me know your feedback!
 
Plombo said:
Okay, PalApply v2.0.1 is now out with support for palettes in .act format. See the post at the top of this thread for how to download it. :)

It doesn't seem like anyone's actually tried using PalApply v2 yet. Anyone who does, please post in this thread and let me know your feedback!

Tried it and works great! Thanks for this update Plombo!
 
Okay, it looks like there will be a v2.0.2, because I've come up with a new improvement.

Palettes from ACT and 8bpp GIF files will always be padded to 256 colors, even though most sprites use a lot less than that. PNG has no such limitation, so detecting and removing the padding at the end of the palette can save a few hundred bytes per file. That might not sound like a lot, but considering that many sprites are already <2KB, it actually shaves off a considerable percentage of the file size.

I probably won't have a build of v2.0.2 up until tomorrow, so now would be a perfect time for more people to try out v2.0.1 and report any issues, so that I can fix them before releasing v2.0.2.
 
I know .png compresses better, but I would have sworn on my grandmother color table size is the same no matter what. Learn something new every day. :P

I've been using v2.0.1 quite a bit last couple of days and thus far no issues at all. Thanks again for the work Plombo.

DC
 
Plombo said:
I probably won't have a build of v2.0.2 up until tomorrow, so now would be a perfect time for more people to try out v2.0.1 and report any issues, so that I can fix them before releasing v2.0.2.

I don't know if anyone's waiting for an update on v2.0.2, but its release has been delayed to the next time I boot Windows, whenever that is. For Linux users compiling it themselves, though, the code changes are already finished on GitHub.
 
I was waiting, but if you think I'm turning in my MSCE for your Penguin gear, forget it!  ;D

I'll see if I can get it to compile on my Windows box. Thanks Plombo!

DC
 
Ok, so I'm a total noob on this issue but I've been meaning to make a topic about other methods of making palettes so this saved a little legwork. For one, I skimmed this topic last night and I got some details down but that was about it, but after going through this again, I think I see the advantages Plombo was going for and what DC was getting at. BTW Plombo, it's been a while homie.  8)

I just DL'ed Palapply2 and tested it on my Pal image I had for Shadow in my Sonic mod, and compared the PNG file to a copy I saved using IrfanView and I noticed the former was a slightly smaller size. Given that I'm ready to start working on a new character, I'm going to use Palapply2 for the Pal file and see how it goes. There was a problem with PNG I ran into some time ago with Venom on Multieverse Meltdown so I went back to GIF, I think I tried to use sprites from a different source that didn't have the same palette, though I saved over the original palette image and it didn't work.

If I have any similar or other issues, I'll come back here. That being said though, I still use MOSWorkshop to change which color is transparent. I'd like to know am I out of date and could use a better app to do this.

X)
 
I felt like booting Windows this evening, so PalApply v2.0.2 is out. Grab it at the GitHub releases page as always. This one is a 32-bit binary, so it should run on any (non-ancient) version of Windows.
 
It turns out there was a bug in all existing versions of PalApply v2, where it would wrongly choose darker colors from the palette for partially transparent pixels. I've released a new version, PalApply v2.0.3, which fixes this issue. As always, you can download the new version from the releases page.
 
thanks for the info, test it, works very nice, awsome tool to have in your box for water transparencies and the like.
 
Back
Top Bottom