My blp files are readable by the game. If your software can't read my files, that's not my problem, it's the software developers' problem.
This is the conclusion I came to earlier when reading the source code. I am not sure why people still thought it was some form of protection attempt...
That said, the issue likely stems from the BGRA component JPEG format used by Warcraft III
not being a standard format. It is my understanding that the original BLP files from Warcraft III (early 2000 release) used Intel's JPEG image library for creation and decoding. This library gave low level access to component channels, allowing JPEG to be used to store general 2D data and not just standard colour components. As such the resulting JPEG images consisted of 4 channels of 8 bit components which represent BGRA data. This is not a standard JPEG format, so how it ends up interpreted is based entirely on the decoder implementation.
Unless... The decoder supports extracting the channels directly. In that case you can extract all 4 channels, map them to their correct BGRA components and use the texture. Java's built in ImageIO decoder for JPEG supports this by loading the JPEG image as a raster with 4 component channels. Most JPEG libraries do not support this, with at least a few, such as the PHP BLP decoder, using colour space conversion from some arbitrary decoded colour space, introducing off-by-one errors in some of the decoded components due to rounding.
Technically, Blizzard storing textures like this was a very poor decision. JPEG is not optimised for storing BGR colour components, instead using colour spaces like YCrCb since humans are most sensitive to luminance and less so to colour. This almost certainly will have resulted in the chosen approach causing larger files for similar image quality, or lower image quality at same file size. Further more the JPEG image has to be decoded anyway, so performing colour space conversion to a BGRA texture is unlikely to have occurred significant load time overhead.
To some extent files created by your software not working in other people's software
is your problem as it affects interoperation with other applications. If it is caused by you knowing something they do not, then it is important that this becomes well known so that those developers can try to fix their implementations for future applications.
I have two JPEG encoding modes depending on the presence of an alpha channel. Try opening this texture.
As far as I am aware there was only 1 JPEG encoding mode used by both? Even with no alpha, the stored JPEG image is still 4 component BGRA. This is why some Blizzard JPEG encoded BLP textures bug out when viewed "correctly", since they were incorrectly defined as having no alpha, encoded with full alpha data and anything rendered in 3D (not UI element) ignored what the texture set for having alpha and always assumed alpha, possibly as a material property or something model defined. UI elements, such as command card buttons, did correctly read the texture alpha flag so it would appear without alpha if used as a button. This was visible in the one campaign background where some of the foliage (TFT Nightelf? Or was it RoC Nightelf?) were using such bugged texture. In game it appeared fine, but if a model viewer "correctly" interpreted the texture declared alpha or if it were used as a command card button then it would appear without an alpha channel and look wrong.
I also found that the shared JPEG header had a maximum size. I am guessing older versions of Warcraft III used a constant sized, possibly statically allocated, piece of memory to hold the shared header and if the header was made too large it could overflow this memory. This stops one doing a trick like having the shared header contain a full JPEG image with the mipmap data being a chunk of 0 bytes long. I do not know the exact size limit on the JPEG header, but I assumed it to be what Blizzard's BLPs used since it would make sense that they optimised the memory allocation for their own files and all files had exactly the same header length.
That said my knowledge of the exact format of the JPEG images used was quite limited. Although Java's JPEG ImageIO library can easily extract and interpret component channels using a raster, any attempt to decode metadata from the image threw an exception saying it was corrupted. As such I could not do something like look up the compression ratio used, and instead had to rely on what BLPLab and other tools reported the images were using.
What do you do differently for encoding between with and without alpha? As that might be one of the aspects that breaks compatibility with other BLP implementations.
which cannot properly load the BLP provided by @RvzerBro, by the way
Out of interest, in what way does it not load properly? Failed to load texture? Corrupted? Largest mipmap levels skipped?
Approved
i am literally running on BattleNet Launcher. Can you please show me your settings of files ? Maybe i have something wrong there.
Today I completed my visual patch for 
)
?
I'm really excited to get this going again 
