8 bpp writing speed
Brought to you by:
macklin01
Menu
▾
▴
Hi, and thanks for this post.
Right now, it's not on the horizon, but I recognize that it's a slow, inefficient algorithm. Currently, each pixel searches for the best fit color in the palette when writing, making it a slow operation. This is the cost of saving each pixel at 32 bit depth (for a unified data structure), but still requiring a best match to the lower-bit palette when saving. There is no guarantee that colors are still in the space of 256 colors when writing, so it performs this search.
If we could guarantee that each pixel matches one of the palette colors, then we could skip this search for the best fit color when writing, with a substantial speedup. Does your application strictly stick to the 256 colors in your palette in all pixel manipulations?
For now, 24-32 bpp is most efficient (for speed). I could find algorithms to speed the search, but it's unfortunately a lower priority for now. However, a shorter-term fix could be to add a specialized function that sets pixels to specific palette colors (effectively enforcing that the pixels are in the space of colors), allowing the write functions to skip the search. Would this work for your application?
Actually, I'm using it for almost all of the bit per pixels. And I convert first the color of the image to grayscale and this lessen the slowness of the writing speed, but still it takes time. Is there other turn around?
Hi, if you're substantially modifying the pixels beyond the original palette, then you should (1) read the image in its original bit depth, (2) do whatever operations you want--everything is internally stored at 32 bpp, (3) set bit depth to 24 or 32 bpp before saving, and (4) save.
Otherwise, whatever changes you've made in 32 bpp quality will be downgraded to 8 bpp when you save, with a corresponding loss of quality and poor write speed.
If you truly want to stick with the 8 bpp and original palette, and I try to cook something up.
I cannot save them in higher bit, you see, in my application if the user intends to convert the image to 8bpp, whether the image tobe converted is 24, 32,8 or 1bpp. So i should stick to 8bpp as an output. That's why i need to lessen the slowness of writing for 8bpp. And yes I'm reading the image from its original bit depth.
I'll try your suggestion, since mostly of the images that i'm using are bank form, letters and then barcodes, so setting pixels to specific palette colors, i hope will not be too much of a problem, so how can i enforce the pixels in the space of colors?
Can be done. But please note that if you've modified the colors beyond the original palette, it might be best to just change to 24 bpp after reading the images, and save as 24 bpp. See the note above.
Depends what's more important to you -- the smaller file size and original palette of 8 bpp, or the higher quality and faster write time of 24 bpp. File size increases by ~ 3x if you read as 8 bpp but save as 24 bpp.
I guess for the time being I have to stick with the smaller file size and original palette of 8 bpp. Since I really need an output of 8bpp.