Standalone DXA Encoder

[dooplex]

I want to do some experiments on the Feeble Files videos like leaving out frames or changing the dimensions. Is there any stand alone DXA encoder which is able to encode SCUMMVM compatible DXAs (from PNGs(?))?

I already had a look at the encode_dxa (from SCUMMVM tools) source code and I think that it needs the SMK files only for meta information (fps, image width, image height, ...). I think, with a bit of work, I could change it to accept these information from the command line myself. Still, I'd prefer an external (= not messed up by me) application for the job .

[Longcat]

And you really had to make another thread about this?

[dooplex]

Sorry, I don't want to clutter the forum. It just seemed that this matter went a bit down in the other thread.

Also, the topic changed a bit from the initial topic of the other thread.

[sev]

No, there is no standalone encoder for that format. Moreover, what we use is a completely new format, different from original DXA as we use more sophisticated compression. That is, it is a ScummVM project format.

Only thing you can do is write something by yourself.


Eugene

[dooplex]

Thanks for your help!

As far as I understand (hopefully) now, a dxa file consists of a DXA header (starting with Byte sequence 'DEXA'), followed by a sequence of images (each starting with 'FRAM').

Each of these images is XORed against it's predecessor (this makes for better compression, as only the differences have to be coded). Each image is then encoded in PNG format.

I got some of my information from here:
http://wiki.multimedia.cx/index.php?title=DXA

I think the main difference between SCUMMVM DXA and 'original' DXA is the PNG compression used in compression of the images, while 'original' DXA used only ZIP.

As PNG is optimized for image compression while ZIP is not, SCUMMVM DXA compresses better than 'original' DXA.

Please correct me if I'm wrong. Maybe there's something like a SCUMMVM DXA specification, too?

[john_doe]

Nope, read sev's reply again. ScummVM DXA is almost completely different from the original DXA, it does not use PNG internally. PNG is only used to transport data from the Smacker tool to the DXA tool. It could also have used PCX etc. but since PNG compresses better I chose it since it needs less temporary storage. And no, there's no official documentation of the ScummVM version format besides the source code. You can also have a look at the decoder source since it's simpler and probably gives you a better understanding of the format.
But if you only want to change image dimensions and not add new encoding schemes, modifing encode_dxa seems the simplest way (simpler than writing another encoder from scratch anyway).

[dooplex]

I just tried to reencode the DXA videos from Feeble Files. I extracted the PNGs, and modified them to keep only 1/4 of the information while maintaining the dimensions.

I did so by resizing the PNGs from BincConv to 50% width/height first (using the lanczos filter), then sizing them back to their original size using a quick/simple resizing algorithm. The resulting images are as pixelated as 320x240 images, but are sized 640x480.

Now, I encoded these images using encode_dxa, and the resulting DXAs are actually a lot bigger than they would have been otherwise.

F.e.
Agent32.dxa (unmodified images) - 2,082,617b
Agent32.dxa (modified images) - 9,415,831b

I'm puzzled about this - how could this be? Maybe the new DXA format uses some special prediction that doesn't fare too good with my experiments?

[eriktorbjorn]

I'm puzzled about this - how could this be? Maybe the new DXA format uses some special prediction that doesn't fare too good with my experiments?

I don't know that much about the DXA encoder - particularly not after it was extended with alternative compression methods - but it used to be that each frame was either a complete representation of that frame, or the difference between that frame and the previous. (Or a "null" frame to indicate that nothing had changed since the last one.)

I imagine that the scaling and filtering could possibly introduce a lot of new colours and/or fuzziness into the picture. That could make the difference between each frame greater than it used to be. Perhaps the entire palette changes between frames so that even the ones that still look identical are completely different.

[dooplex]

Yes, this might be the case. By resizing the image to half width/height, four pixels become one, and the average of the four is used for that one pixel. It becomes even worse as I used the Lanczos filter (I don't know what this actually does). This way new colors are introduced. Palette changes worsen the problem even more.

Two images that were exactly the same before should stay that way, though.

[eriktorbjorn]

It becomes even worse as I used the Lanczos filter (I don't know what this actually does).

I only know what Wikipedia says, and I can't say I understand it.

Before anyone asks: This method is probably much too slow to ever be used as a graphics filter in ScummVM.

[Anotherguest]

Lancos filter interpolates colours when scaling down, making it use many new different colours to reflect the original picture better (in a fuzzy way). Not good to compress videos though.

[john_doe]

Yes, the size difference is due to the "noise" introduced by the Lanczos scaling. E.g. the DXA method 13 compresses a 4x4 pixel block which has only one color as 1 byte, while a block with too many colors may use up to 16 bytes, which is probably the case here.
Also, the encoder relies on the (lossy) preprocessing done by the Smacker encoder since the DXA encoder itself is very simple and doesn't do any lossy processing itself.
You could try to encode the new PNGs with the Smacker encoder and then use the new SMK.

[marticus]

It might work if you do a shrink that just discards every other pixel and then do a nearest neighbour resize.