Jump to content


Sam.

Member Since 10 Jun 2008
Offline Last Active Today, 02:50 AM

Posts I've Made

In Topic: PS BAM

26 November 2018 - 06:39 PM

Edit: I am currently making animations gif files for my readme. Is there a way to export a bam file into fig with a transparent background and a semi-transparent shadow color? I guess not, but who knows, maybe you are a magician...

Well, the GIF file format doesn't support semi-transparency, so that's out.  You can specify a transparent color for the background, tho (which PS BAM is supposed to do).

 

You can export each sequence as a separate animated GIF using:

"D:\Program Files\GitHub Projects\PS-BAM\PS BAM_x64.exe" --Compress 0 --OrderOfOperations C --SingleGIF 0 --DebugLevelL 1 --DebugLevelP 2 --DebugLevelS 1 --LogFile "D:\AutoHotkey Scripts\PS BAM\MooseN\Log.txt" --OutPath "D:\AutoHotkey Scripts\PS BAM\MooseN\GIF Example" --Save "GIF" "D:\AutoHotkey Scripts\PS BAM\test\AMOOG11.BAM"

AMOOG11_Sequence_0002.gif

or you can export EVERY frame in the BAM into a single GIF via:

"D:\Program Files\GitHub Projects\PS-BAM\PS BAM_x64.exe" --Compress 0 --OrderOfOperations C --SingleGIF 1 --DebugLevelL 1 --DebugLevelP 2 --DebugLevelS 1 --LogFile "D:\AutoHotkey Scripts\PS BAM\MooseN\Log.txt" --OutPath "D:\AutoHotkey Scripts\PS BAM\MooseN\GIF Example" --Save "GIF" "D:\AutoHotkey Scripts\PS BAM\test\AMOOG11.BAM"

AMOOG11.gif

 

Edit:  Well, I'm not sure why the forum software isn't playing the animations...

Edit2:  Uploaded externally instead.


In Topic: PS BAM

25 November 2018 - 05:31 PM

I have updated 2)  Very Good (Hyper) Compression of BAM V1 Files to include at least a cursory explanation for all the compression options.  That probably covers half of what there is to document considering I've barely scratched the surface of import, processing, and export operations :( .  As always, if you have questions or need more clarification, please ask.

 

@Gwendolyne,

Have you had a chance to play around with compressing your animations yet?


In Topic: Thrown Hammers

22 November 2018 - 01:30 PM

is this mod compatible with item revisions ?

I've never used item revisions, and there is no code in the mod specifically tailored to IR.  Is it incompatible in any critical way?  I doubt it.  Beyond that, I really don't know.


In Topic: PS BAM

20 November 2018 - 09:02 AM

Sam, it's been a long time I wanted to test PS BAM to compress the thousands creature animation files I need to install, but always postponed it because of the lack of documentation.

 

What would be the best command line options, let's say to decompress-recompress all bam files in MYMOD/bam/cre/list of directories, that would produce a significant files size reduction?

 

Edit : games compatibility (ToB and BG2EE might be enough to be fully compatible with BGT and EET).

I'm slowly trying to work on documentation, but there is a lot to document.  Some options are fairly strait forward (I bet you can guess what --DropUnusedFrameData does), but others require a much more technical and detailed explanation in order to get a good understanding of what it does or how it should be used (--AdvancedFLTCompression and the corresponding --FLTSanityCutoff for instance).  I'll try to do some more this week/weekend.

 

As for what are the best options for compression, that really depends on what your goals are and how much time you want to spend on compression.  When I get around to compressing Infinity Animations, my plan is to crank compression way up and use three quad-core computers with a different instance of PS BAM running on each core and let it run for a few days.  That is undoubtedly excessive compared to what most people will want to do.  What I used in tutorial "2)  Very Good (Hyper) Compression of BAM V1 Files" is a good place to start, but consider turning --zopfliIterations down a bit as I suggested.  There are enough options it's worth taking the time to make some informed decisions about which options you want to use (again, working on documentation...).

 

I'll try to give you an idea of the possible scope of your options.  I personally think of the various compression options as divided into three categories:  mathematically lossless, visually lossless, and visually lossy.  Examples of mathematically lossless include RLE, z-lib compression, and because of how PS BAM reads BAMs, usually even dropping duplicate frames and frame entries.  I term them mathematically lossless because these things can be undone to get exactly the same file you started with.  Visually lossless include things like trimming transparent pixels from frames and dropping unused palette entries, frame entries, frames, etc.  Visually lossless means pixel per pixel, the displayed BAMs will be identical before and after the operation, but the operations can never be undone.  Lastly, visually lossy includes operations that actually alter the appearance of a BAM.  For example,

--AlphaCutoff 10

is used to transform nearly transparent pixels into the fully transparent background color, thus freeing up palette entries that can be dropped and potentially increasing how many transparent pixels can be trimmed from the frame.  In BAMs, alpha values range from 1 (nearly transparent) to 255 (fully opaque) with 0 also representing fully opaque for backwards compatibility.  In this particular case, we are setting any color with an alpha value between 1 and 10 inclusive to the background (transparent) color.  It is technically visually lossy, but I challenge you to see the difference.

 

Here's a second example of a visually lossy option.  I exported the frames from MDR11207.bam using:

"D:\AutoHotkey Scripts\PS BAM\PS BAM.ahk" --Compress 0 --OrderOfOperations "E" --ExportFrames "PNG" --DebugLevelL 1 --DebugLevelP 2 --DebugLevelS 1 --LogFile "C:\Users\Sam\Desktop\Export\Log.txt" --OutPath "C:\Users\Sam\Desktop\Export\Extract" --Save "" "C:\Users\Sam\Desktop\Export\MDR11207.bam"

Attached File  MDR11207_Frame_0092.png   10.75K   5 downloads

You will notice some "garbage" pixels towards the upper right corner of this frame.  These pixels are not part of the animation, and would block the frame from being trimmed from the top using the standard

--TrimFrameData 1

However, PS BAM provides some more advanced options capable of trimming these garbage pixels:

--ExtraTrimBuffer 2 --ExtraTrimDepth 3

ExtraTrimDepth specifies the maximum number of rows that can contain non-transparent color pixels to be considered for trimming.  ExtraTrimBuffer specifies the minimum number of fully transparent rows that must separate the non-transparent rows from any others before they will be trimmed.  To put it another way, going from the top edge down, we can have up to three rows of pixels that are not fully transparent.  They are followed by at least two rows that are fully transparent, therefore they will be removed.

"D:\AutoHotkey Scripts\PS BAM\PS BAM.ahk" --OrderOfOperations "CE" --TrimFrameData 1 --ExtraTrimBuffer 2 --ExtraTrimDepth 3 --ExportFrames "PNG" --DebugLevelL 1 --DebugLevelP 2 --DebugLevelS 1 --LogFile "C:\Users\Sam\Desktop\Export\Log.txt" --OutPath "C:\Users\Sam\Desktop\Export\Extract" --Save "" "C:\Users\Sam\Desktop\Export\MDR11207.bam"

Yields

Attached File  MDR11207_Frame_0092.png   10.32K   5 downloads

Beware, however, because this can sometimes trim legitimate pixels also.  Consider a character's sword animation where the pommel is only a few pixels followed by several rows of transparent pixels where the character's hand would go.


In Topic: PS BAM

20 November 2018 - 07:32 AM

In the era of EEs where the recommended practice is to not biff your override folder, PS BAM is capable of compressing BAMs even smaller than can be achieved by biffing them.  

Biffing had nothing to do with the size... it's about the speed at which the data can be read. At time when RAM was not a thing ... yet.

This statement is simply not true, for multiple reasons.  I was tempted to just ignore it, but an explanation has some relevance to the topic at hand.

 

Biffing had nothing to do with the size...

When files are added to a BIFC V1 or BIFC V1.0 archive file (aka biffed), they are z-lib compressed.  This reduces the filesize (with a caveat I'll explain in a minute).  Furthermore, it is more efficient (in terms of size) to store one large file instead of many small ones.  Quoth IESDP concerning the BIFF file format:

 

This file format is a simple archive format, used mainly both to simplify organization of the files by grouping logically related files together (especially for areas). There is also a gain from having few large files rather than many small files, due to the wastage in the FAT and NTFS file systems.

Go look up the difference between file size and size on disk.

 

Now the caveat:  When a BAM V1 (as opposed to a BAMC V1) is added to a BIF it becomes z-lib compressed which reduces its size.  A BAMC file, however, is already z-lib compressed and adding it to a BIF will force it to be z-lib compressed again which does not gain you anything.  PS BAM uses zopfli to perform zlib-compatible compression.  Zopfli offers better compression ratios than the z-lib library itself (at the cost of more processing time).  If you try to biff a file compressed with zopfli, the resulting filesize will increase not decrease, so don't do it.

 

 

At time when RAM was not a thing ... yet.

RAM has been around since like the 1970s and is almost exclusively volatile memory.  Perhaps you are referring to SSDs which usually use non-volatile NAND flash memory?

 

it's about the speed at which the data can be read.

Storing a single file instead of many small files does have the added benefit of faster data access due to consecutive vs nonconsecutive RW operations on electromechanical and optical drives.  However, as pointed out earlier, this is not the only benefit.