Hey, I would like to ask you something about the Button Manager.
I just noticed, you could apply any border to any image, if using your tool.
Could you imagine extending it and offer any size, instead of the initial cut-out and 64x64 ? This could allow users to create a Warcraft-like tooltip, for example, instead of having to print a screenie, cutting out, formatting and so on.
I would be very grateful if the Button Manager would support any size and re-size and maybe an option to create a Warcraft tooltip ( like adding text with hex-code and get the tooltip printed).
What do you think about such a feature ?
Well there is also SetPixels for whole areas. I have already integrated it in my custom object editor. It is just for previewing purposes, so I can pick the correct resource paths and browse to find something fitting. All the original files from the mpqs are pre-extracted.
In Java, I switched to JPEGImageDecoder and decoded it as a Raster, in this Raster iterated over all pixels to swap first and third value (red and blue). Using this Raster and a sRGB ColorModel with alpha for the 4th component formed the correct BufferedImage.
The decoder in vb on the other hand not only had red/blue swapped but also the values were inversed (255 - red/green/blue/alpha). The main issue however was the encoder I threw in between, I just wanted to save it as a stream to pass it further but it jumbled up everything.
Seems like there was a problem with jumping back to the beginning of the file, so the offset the mipmap data was taken from was wrong. Also the decoder in vb expected the memorystream to be reverted. Now I handle the streaming in an own array and rewrote the script in java.
You are right about the colors being off. They are unsaturated and the hue is incorrect. Photoshop deems it as CMYK. Some programs cannot open it at all. I have not succeeded in configuring the decoders yet.
The vb one appears to be readonly after construction and the constructors do not exactly let you specify a color space. There is an option "PreservePixelFormat", so maybe one should instead inject a color profile in the jpeg.
In java I tried the general ImageIO, which provides a stream you can pass to BufferedImage. From there you can create a 2nd BufferedImage with another color model and draw the first one on it. But I do not get a right result either. So I have not found out yet how to state the color model in the decoder nor how to mark the color profile you mentioned within the jpeg.
You can transform the BufferedImage with
BufferedImage after = new BufferedImage(width, height, BufferedImage.TYPE_4BYTE_ABGR);
AffineTransform at = AffineTransform.getScaleInstance(1, 1);
AffineTransformOp scaleOp = new AffineTransformOp(at, AffineTransformOp.TYPE_BILINEAR);
after = scaleOp.filter(bufImg, after);yet none of the types available make it look right.
edit: Since people mention that you should not access the underlying baseStream that way, because streamReader buffers the data instead of reading directly from the source everytime, I also tried to close/reopen and senselessly reading in mipmapOffset bytes just to push the cursor. It did not help either. The decoder says the image header might be damaged.
state that the jpg data is obtained by taking the header in the jpg-branch and merging it with the data of a mipmap. This however does not seem to be enough, since all programs complain about an invalid format. The sizes and offsets match those displayed in your BLPLab, the header has the right usual 0x270 length. Are the offsets from beginning of the blp file or from the jpg part? What I extract (in my example) misses like 15*16 bytes to get to the end token "FFD9" jpgs are expected to possess.