Load a JPG image with alpha enabled
Blitz3D Forums/Blitz3D Programming/Load a JPG image with alpha enabled
| ||
| Hi there, I need to load jpg pictures, but I need also to have an alpha channel. If I just load the jpg using: t = LoadTexture("test.jpg",1+2) Blitz set the black color as transparent and other as opaque (that's expected). Actually, as a workaround I do the following just after the loading: LockBuffer TextureBuffer(t) For x=0 To w-1 For y=0 To h-1 p = ReadPixelFast(x,y,TextureBuffer(t)) p = p Or $ff000000 WritePixelFast(x,y,p,TextureBuffer(t)) Next Next UnlockBuffer TextureBuffer(t) That is: I am changing each pixel alpha to 255. Problem with this method: it is slow. It takes 300 ms on my test picture and it is really too long for me (I am loading many pictures like this) Question is: is there a trick (maybe using FastExtension) to load a jpg faster with alpha channel enabled and set to 255 for each pixels? I tried also to create an alpha texture, then load my jpeg texture without alpha flag, then copy the loaded texture to the created one, but it does not work either... Any idea? |
| ||
| JPEG format does not contain an alpha channel. So the "work around" is to use PNG format instead. |
| ||
| yes, I know. But PNG files are a lot bigger than JPG. I was using PNG in the past, but I have to switch to JPG. I found a little trick in the meantime: I am loading jpeg with flag 4 instead of 2 (mask instead of alpha). This way only the full black pixels are transparent (but the alpha data are here). And before importing it, I change all full black pixels to R:1 G:1 B:1 on my c# program (which run faster). Not perfect but better. |
| ||
| Not perfect but another possibility maybe is to have 1 blank PNG with the alpha channel - load that and copy the texture then load the JPEG, copyrect to the copy of the blank PNG texture, then unload the JPEG - should be pretty speedy. You may also wish to consider using DXT - depending on requirements .dds textures can be upto 4x smaller than the original PNG + small overhead for alpha - while retaining full or near full quality. Last edited 2011 |
| ||
| yes, I know. But PNG files are a lot bigger than JPG. The reason for that is, they contain an alpha channel and the benefit of lossless compression.JPEG is a really crappy format for anything like this. [edit] Plus, a 512x512 PNG takes up exactly the same amount of VRAM as a 512x512 JPG - regardless of any compression. Last edited 2011 |
| ||
| GfK: I know that. Let say I have 100 pictures. When displaying these pictures I want to make the border rounded. For doing that I use the alpha channel. (I could also use multi-texturing with an alpha texture, but it would use a lot more of graphical memory). So, in the past I converted all these pictures from JPEG to PNG and everything was fine on display. Except that a typical picture JPEG (1024x768) will be like 100kb size, but more like 1-2MB when converted to PNG. So, in the past, for storing 100 pictures I took 200Mb on disk, and I would like to reduce this size. Using JPEG I am only using 10Mb, but I have to do some post-processing. That's why I am messing around that. Rroff: I tried the trick but it seems copyrect copy also the alpha values, so the alpha values of the blank png are overwritten. |
| ||
| Writepixelfast is faster when you first read all pixels to a bank or array, then write all altered pixels back to the texture. Continous alternation (read/write) may slow down things, it's the bus that needs to "drive down the road and back" for every single int. Maybe it will be even faster when you sync this with Vwait. You may also think about to use PNG for the alpha channel and JPG for RGB, then combine them during loading. |
| ||
| Continous alternation (read/write) may slow down things Something that hadn't occured to me - will have to add that to my notes. |
| ||
| Well, I only remember it was useful to increase the speed of such writepixel stuff. Edit - actually the diffrence isn't that big: result (Notebook with a VIA Esther cpu, 1.5 ghz with S3 onboard Graphics) is: 1720 1403 |
| ||
| Its about 12% faster on my newer nVidia/core 2 setups too while not a massive boost its nothing to sniff at either - saving 10% here, 10% there, etc. can be a big gain in overall application performance. Last edited 2011 |
| ||
| PNGs can have an adaptive filter (using different filters per line of image by identifying, per line, the one which would make the most optimized compression). This has a very big impact on the final file size, and is the best choice for compression. Last edited 2011 |
| ||
| You cannot do alpha with JPG beecause it is only a 24 bit format... In fact using even oldskool color mask on jpg will not work well due to artifacting. JPG should ONLY really be used for images that are solid and have almost every pixel of differing color (eg photographic/detailed textures) For this it is an excellent format for quality-vs-size (at least when saved at about 80% compression, any lower and it starts to show). For mask-color transparency -vs- size the best format is GIF-8 although i cannot remember if bb supports it, (it only supports color mask transparency afaik and has limited colors) For proper alpha your options are PNG-32 or TGA-32 (png is better imo) I always use JPG and PNG (as appropriate to useage) Last edited 2011 |
   |