File compression the way I see it is where the goal is to reduce the file size as much as possible without the loss of data. This is generally utilized when you have lots of repeated strings of data (ie lots of 00s etc), the same technique is also used in lossless image formats such as PNG. Lossy compression, which is something used in images and audio (obviously including video as well) is where the goal is to compress the data, losing some of the data at the same time in order to get a smaller image but is still visibly acceptable/appealing. If you recall seeing JPEGs with lots of like specky dirt on them, that's the result of lossy compression and the more it is compressed, especially when the process is repeated on the same image, the worser it gets. This can be done in a variety of ways making it rather difficult to just edit an image in a tile editor since you aren't dealing with raw information.
ctool can decompress some some texture formats which includes the texture compression format used in NDS games, however atm the only option you have with them is to save a raw copy of the image to the clipboard, thus losing palette information and so forth. As I've already pointed out, you'll probably have to jump between versions in order to get to this point as certain functionality was only supported in specific past versions. This will all change of course starting from the next version (at least I am hoping so), but for now that's the best I can offer to your problem.
I'm also not a real expert with compression algorithms so I'm quite happy if I'm just able to decompress something with 100s of errors. But to write a proper compressor (even a simple one) will be a lot of work and I most certainly don't plan on racking my brain anytime soon :/
But although re-compressing your edited graphics might not be feasible atm you can still technically modify them, it just that you'd have to either save them in raw 16-bit color format (that's RGB5 with no alpha) or as 256-color paletted image. Both instances you obviously lose your alpha channel (although I don't think this specific file uses alpha anyways), and generally will have a larger file size too.
On closer inspect, that file actually has a LOT of alpha channel usage including translucent effects. Your best option would be to create the translated graphics from scratch and then convert them in (I'm assume you're doing a translation here?).
Here's the texture data extracted as an NSBTX.http://www.mediafire.com/?zywh7m1r6qje7na
In an effort to better understand 3D Modelling in the NDS I've sort of branched out and had a look at some other games with a strong emphasis on 3D. For now this would include Star Fox Command and Kingdom Hearts 368/2 Days.
Star Fox Command has a lot of raw data files including a custom container format with the magic stamp "chnk". It's an odd format in that every node is preceeded with the chnk header, which both defines the objects type and where or not it is a sub chnk or a data file. All data types a preceeded with "MGL" which I'm guessing is the short name of the sdk used to build the game.
So far I have figured out MGL Palettes, Textures, and have partially figured out Mesh files which are actually 90% DS geometry commands making them fairly easy to add support for. The fact that even header chunks in Mesh files were actually command dumps got me looking at unknown data in the Official SDK formats with that in mind and has helped me figure out a few more things
Moving on to KH368/2 Days there is an absolute ton of Model resources to sift through in it, most of which are hidden away in countless container formats. To that end, I've started to put together a few specs on the container formats, since a general google search turned up next to nothing or very poorly written documentation.
$0000 4 Magic "KAPH" or "D2KP"
$0004 4 Padding
$0008 4 0 FAT
$000C 4 1 FAT
$0010 4 2 FAT
$0014 4 3 FAT
$0018 4 4 FAT
$001C 4 5 FAT
$0020 4 6 FAT
$0024 4 7 FAT
$0000 4 Number of Files
// Repeats * Number of Files
// Offsets Block
$0004 4 Offset
// Lengths Block
$0008 4 Length
// Types for KAPH
// Types for D2KP
A few things to note is that KAPH files deal with 3D and D2KP deal with 2D, but the file structure is identical other than what files are stored in each FAT table.
$0000 2 Magic "P2"
$0002 1 Number of Files
$0003 1 Has Name Table Flag (00h=No, 80h=Yes)
$0004 8 Padding[00h]
$000C 4 Header Size (0x200, 0x400, etc)
Offsets Table = 0x10
Lengths Table = offTable + Math.ceil(numFiles/2) * 2 * 2
Names Table = lenTable + numFiles * 4
// Repeat * Number of Files
// Offsets Table
$0000 2 File Offset * 0x200 + headerSize
// Lengths Table
$0000 4 File Length & 0xFFFFFF
Type (>> 24) & 0xFF (00h or 80h)
// Names Table (Not always present!!)
$0000 8 File Name
This was a bit of a pain to figure out and still might be somewhat buggy, but as far as I can tell this should work on most P2 files.
$0000 4 Magic 0x0C000000
$0004 4 Length 1
$0008 4 Length 2 (Seems to coincide with File Size)
$000C 4 Number of Files
// Each file begins with a header block which allows
// the parser to jump to the next file in the archive
// until Number of Files is reached
// File Header
$0000 4 File Size (includes 8 byte header)
$0004 4 File ID
Now looking at the models about 80-90% have at least one spastic vertex with others that look terrible. This could be happening due to a number of reasons including the likely possibility that the rendering order which ctool loads them is wrong (ie a polygon is drawn before the matrix stack is loaded appropriately).
There is also the bone command 09h. Although some models that have it still appear to load properly, I'm sure this command has some significance due to the data length. It is a variable length command which from what I can tell must somehow load/copy/clone other stacks into empty stacks with some possible calculations done on them in the process.
Here's a sample 09h command:
09 05 03 010140 040540 030480
09h Command ID
05h Target Stack ID
03h # Sources
// Source Data 1
01h Source Stack ID
01h ?? ID
// Source Data 2
04h Source Stack ID
05h ?? ID
// Source Data 3
03h Source Stack ID
04h ?? ID
The number of sources can be either 2 or 3 as far as I've so far seen. Just looking at the data, its clear it wants to do something with the stack, as the stack IDs all refer to previously assigned stacks, however its the last two variables in each source data that's got me stumped. Particularly the last variable, which can have a seriously varying value.