Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » How to use RLE compression to print a series bmp images?
|
|
Re: How to use RLE compression to print a series bmp images? [message #3688 is a reply to message #3683] |
Mon, 12 June 2006 21:43 |
|
fudadmin
Messages: 1321 Registered: November 2005 Location: Kaunas, Lithuania
|
Ultimate Contributor Administrator |
|
|
luzr wrote on Mon, 12 June 2006 17:26 |
fudadmin wrote on Mon, 12 June 2006 11:03 | Ok, then, forget agg. Let's say how is it possible to save bandwidth when printing a series bmp images? Use RLE compression?
|
I am sorry I have confused you with "RLE" term... It is rather "RLE-like"...
DrawData performs this automatically. Just see DrawData.cpp.
Note: I plan to provide similar optimization for all images scaled up for printer. At the moment, it is ToDo...
Note2: Maybe this "RLE-like compression" looks stupid, but it is already tested in practice and works indeed very well...
Note3: Please really do make a look at DrawData.cpp, DrawDataOp. It will save a lot of time and posts
Mirek
|
1. to Note2 - please don't have any impressions that I suspect your ideas stupid. Quite opposite. I want to learn the best parts of your programmers thinking (if not all...).
2. Are you talking about an alternative to png and jpg image format?
3. As I understand from DrawDataOp, it goes "fishing" for one color rectangles (bigger than something) and then outputs them with DrawRect (hardware accelerated) while "to small to bother" - "hardware not digestive" other areas are optimally "rectangalized" into image rectangles and pumped as RGBA pixels?
(Just can't find where palette colors come into game...)
this is at least what I think would be effective...
|
|
|
Re: How to use RLE compression to print a series bmp images? [message #3689 is a reply to message #3688] |
Mon, 12 June 2006 22:05 |
|
mirek
Messages: 14038 Registered: November 2005
|
Ultimate Member |
|
|
fudadmin wrote on Mon, 12 June 2006 15:43 |
1. to Note2 - please don't have any impressions that I suspect your ideas stupid. Quite opposite. I want to learn the best parts of your programmers thinking (if not all...).
2. Are you talking about an alternative to png and jpg image format?
3. As I understand from DrawDataOp, it goes "fishing" for one color rectangles (bigger than something) and then outputs them with DrawRect (hardware accelerated) while "to small to bother" - "hardware not digestive" other areas are optimally "rectangalized" into image rectangles and pumped as RGBA pixels?
(Just can't find where palette colors come into game...)
this is at least what I think would be effective...
|
Well, finally gettin somewhere
JPG and PNG do not play a big role here. Perhaps you are confused by the fact that at the same time, the only registered data format is "file-format", which covers JPG and PNG, however, this is helpful in storing the image to Drawing and in fact, data can by anything - software rendering recording being the very important option.
Pallette colors are least useful thing here - printers are never palette devices. IMHO, it is best to feed the full 24-bit color to printer in any case and let printer driver decide the best way of rendering it. Note also that a lot of printers are actually 24-bit color inkjets....
What I believe does help however is detecting those uniform color areas. E.g. while printing those scanned B&W documents (my major testcase), it reduces the amount of data send to printer driver by 80%.
Mirek
|
|
|
|
|
Goto Forum:
Current Time: Fri Sep 20 03:41:46 CEST 2024
Total time taken to generate the page: 0.03288 seconds
|