Allow greater flexibility with the trim feature

[JannikGM]

I'd love to use the trim feature, but I'm packing RGBA images together with data encoded to RGBA. It's not untypical to have an alpha channel of 0 where the RGB data is still very important.

I'm not sure if the trim feature already considers this case or wether it looks at alpha in isolation. Ideally, for me, it would trim only when a very specific color-code is found (like rgba(0,0,0,0)), so we can make safe assumptions.

(Specifically, I need this in the CLI version, but I assume this issue tracker goes for both)

[odrick]

This is a very rare feature. And yes, right now ftp trimms by alpha only. I can suggest you to fork the project and implement the required functionality. Look at utils/Trimmer.js, https://github.com/odrick/free-tex-packer-core/blob/master/utils/Trimmer.js . Something like:

static getAlpha(data, width, x, y) {
    let pos = ((y * (width * 4)) + (x * 4));

    let r = data[pos];
    let g = data[pos + 1];
    let b = data[pos + 2];
    let a = data[pos + 3];

    if(r === 0 && g === 0 && b === 0) {
        return a;
    }

    return 1; 
}

[JannikGM]

This is a very rare feature.

My use-case is, but in general this should be an extremely common use-case, because it allows for additive blending if textures are stored in pre-multiplied alpha: https://github.com/dtrebilco/PreMulAlpha#the-three-in-one-blend-mode

So alpha = 0, but color in RGB, is often seen with particle systems (which is exactly when you'll want to use an atlas, so you can have many different particles in the same texture).