http://dl.dropbox.com/u/51368068/vomarz_pvrcvt.rar
This works from the command line, it converts PS2 PVR files to TGA files.
It requires a PVR and a CLUT. It's been months, I dont remember how to tell what the CLUT files are.
Some of the PVR are 8-bit and others are 4-bit, you have to sort out which is which and what CLUT files they go with on your own.
CLUT (not CULT) is short for Colo(u)r Look-Up Table, sometimes it's called a palette
Basically it's http://en.wikipedia.org/wiki/Paint_by_number, you have a palette of colors (let's say 1 to 4)
the palette is definied (in your case in an external file, NOT in the files provided, look at other files in the same directory)
in a certain color space (e.g. as R8G8B8 with alpha or just R5G6B5 or as luminance ...)
I forgot to say why CLUTs are/were used:
A single pixel only has 2 bits instead of the full 32 bit it would take for R8G8B8A8 (in the example above), see example below to see how much this saves
They were primarily used to save space in the 'old' days, nowadays CLUTs are getting rare (but they aren't gone)
An easy example: You have a R5G6B5 colorspace (quite common on the PSP) so 16 bits = 2 bytes per pixel
Now that would be (for a 64x64 image): 64*64*2 bytes = 8192 bytes(8 KibiByte or 8.192 KiloByte)
Assume there are only 32 different colors in this 64x64 picture (or reduce them to the 32 most used)
We make a CLUT of 32 colors with the length of 2 bytes (one color needs 5+6+5 bit = 2 bytes) = 64 bytes
Now we can address each pixel with just 5 bit (2^5 = 32 different colors) instead of using the full R5G6B5 notation (5+6+5 = 16 bit)
So CLUT + image data: 64 bytes + (64 * 64 * (5/8) byte) = 2624 bytes
So basically CLUT's are often used when you know that the range of colors you're going to be using is limited (either by the dev, or by other factors like software/hardware)
the clut files that virtual on uses with its pvr files are used to save space because multiple textures use the same colors and the color space is small. the SVP fileswere ripped from the Ninja containers. There is an issue with texture coordinates or something though and the objects don't look correct when textured.
and just to clarify the difference between dreamcast and ps2 pvr textures, ps2 textures have a flag that specifies if the pixel data is swizzled or not and you have to handle it accordingly. iirc you also have to handle palettes in ps2 format. there may be an alpha issue with my converter also, I ran into the same issue with rtype final. I'm not familiar enough with ps2 hardware but the alpha values seem to be 16-bit or possible 32-bit signed but it seems well enough they way I deal with it.
another note about pvr and nj models, pvr files have a sub header with the magic GBIX. the GBIX header defines a global identifier for that the ninja system uses. the nj models refer to this identifier to pick what texture they use.
also a note about vo: marz. the japanese version is pretty interesting because the symbols weren't stripped from the executable. static analysis is a pain and pcsx2 doesn't have a functional debugger, but it should be possible to reverse engineer the entire ninja system from rofs encryption to handling models and textures in great detail. I'm not that interested but the possibility exists.
Because you hand ripped them there isn't really anything I can do, sorry. Is there a particular texture that you were looking for, I could maybe help with that.