Hi there halumi, really grateful for your L.O.L. translation (hilarious translation group acronym btw
) and cheers for tackling a PS2 translation. You don't see much of this these days.
I will cut to the chase:
You probably know a lot of what I'm about to say next, but for the sake of the idea flow I will need to point it out anyways.
Most old-school formats are stored in a way that each pixel never has the actual RGB color value, but instead has an index (hence why these images are called indexed color images). That index is one out of a number of entries in a table with the actual RGB color values, that table is called the palette (or sometimes the CLUT for "color look-up table" in a Sony context). Of course the exact specifics of how this is represented in hexadecimal data depends on the target console's conventions.
The prime motive of this is to drive down the memory cost of storing the image, either in the static game image (ROM, game disks) or the runtime memory (RAM), and as a neat side effect reduce loading and processing times. So as you might have guessed, while there are formats that directly encode each pixels to their RGB value (meaning every single pixel is encoded in data as a number from 0 to 16 million, if not more, and that makes for a looong file, but they often count on compression to cut it down) this tradition has never let down really.
You seem to be expecting a new tool to be made for scratch to handle .TI files. It would read the header, extract the palette, process the image data accordingly and output a neat png file.
However, in case this didn't ever pan out, and you need to get stuff done anyways, here's an alternate method.
You run all of the file, header, palette and graphics, in a tile editor (crystaltile2) with the settings given above. You still get an editable preview of the graphics (just keep in mind some colors are meant to be transparent as Mugi said), and some garbage at the top that's very clearly non-image data that you shouldn't probably paint over since it's not meant to be handled that way.
The main problem is the colors.
It's off here because Crystaltile2 just uses a placeholder palette for the lack of anything better to interpret that indexed color image, and expects you to give you (under the palette tab, import button) a working palette file (pal/act format) with 256 colors.
The palette data is there, in this very file, stored from 0x30 to 0x42F. Normally you can select it in Ct2, right click (palette to data conversion) and it will overwrite the palette, but the problem is that this conversion works only for palettes formatted for the GBA/NDS systems, and the PS2 uses something slightly different (and apparently twice as big).
Your only remaining roadblock would be to code a tool that converts that PS2 palette to a working pal file (presumably after reading a lot about how PS2 palettes work), and load that in Crystaltile2.
It's a half-measure solution by all definitions of the term, but it's better than nothing, which is why I'm mentioning it here at all in case you're stumped. For simpler graphics like the fonts, you could even overwrite the default palette by a custom "made-up" handmade palette to get it done.
If you're fixing the font, please don't bother coding a VWF routine for it if you know it will be more trouble to debug and test. Just make it fixed width but with a smaller width like any low budget publisher who would like to get its game out asap would do. Some letters will need to be redrawn more centered, but that will be good enough for a game like this.
Please figure out the text pointer system as well. There's only so far hex editing in a translation will take you, before you'll have to butcher it to make it fit. In case it's still too hard to fit in the translation, you could spare the effort you would have put into the VWF routine, to instead add ASCII support and if possible, even dictionary compression support (a shift-jis value would call an entire word instead, for example).