[patch] Minor improvements to image writer and reader January 08, 2010, 12:05:44 pm The attached patch fixes 2 things:1) Currently, images in pak file stores the x-offset, but the image data has not trimmed the left transparent pixels according to the x-offset (by trim, here just means reducing the length of the first clear run), which is somewhat inconsistent. Left-trimming is nevertheless done, but postponed to the reader, which has to go through the image data again to do the trimming, which is inefficient.This patch moves the left-trimming function back to the writer, which is more efficient and make the pak file image consistent in itself.2)For each image line, if the last sequence of pixels are transparent before the line break, the lengths for the clear run and the colored run are still appended to the image data. However, they are actually superfluous and waste harddisk space, memory, and processing time, albeit the impact is rather small. Anyway, waste is waste and we should avoid it, and this patch also eliminates such useless image data.I have made 2 tests and here are the outcome : Fabio's wholesale material warehouse => before : 535KB ; after : 522KB Pak64 factories all in 1 pak file => before : 743KB ; after : 706KBI have tested those output files and they work without problem in Simutrans. Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #1 – January 30, 2010, 08:42:36 am May I know if the above patch is really incorporated in trunk? I can't see it in the repository at the moment.Actually I want to add something to this patch (namely, to apply point 2 above to rezoom_img() as well), but since it has never been moved to the considered patch section, I thought it was rejected and thus didn't bother to do it. Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #2 – January 30, 2010, 08:46:19 am Sorry, apparently moved to the wrong board .. should go to considered. Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #3 – January 30, 2010, 08:49:24 am Never mind, Dwachs, and thanks for your clarification. I will issue a new patch then with the aforementioned addition. Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #4 – January 30, 2010, 11:06:40 am Sounds like a good patch, thank you for cleaning up these parts of the code Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #5 – January 31, 2010, 05:53:08 pm Thanks, Hajo. An updated patch as described above. Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #6 – January 31, 2010, 06:54:12 pm It looks like TileCutter (does that use the standard writer code?) can produce many identical 'squares' -- particularly blank ones, or when parts of a large image repeat in the various rotations. Any thoughts on whether checking and re-using identical picture segments would be worthwhile in terms of space? Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #7 – January 31, 2010, 07:57:50 pm Identical pictures are checked by the register_image routine and will be merged in the program. That way is most effective, especially for empty asphalt/gr****/water (****uming standard water is used). Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #8 – January 31, 2010, 08:18:33 pm Quote from: Knightly – on January 08, 2010, 12:05:44 pmI have made 2 tests and here are the outcome : Fabio's wholesale material warehouse => before : 535KB ; after : 522KB Pak64 factories all in 1 pak file => before : 743KB ; after : 706KBI have tested those output files and they work without problem in Simutrans.You may wish to test it also with my latest electronics plant, as it is a rather huge image... Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #9 – January 31, 2010, 08:54:49 pm Quote from: fabio – on January 31, 2010, 08:18:33 pmYou may wish to test it also with my latest electronics plant, as it is a rather huge image...Thanks for your suggestion . Results are :Before : 1823KB vs After : 1770KB53KB (2.9%) reduction in sizeActually, the percentage of reduction does not vary much even if there are more tiles of images inside the pak. It depends more on the tile size -- you can expect relatively higher reduction rate for pak64 than for pak128, as there are on average fewer coloured pixels per pixel line in pak64 image tiles.Anyway, the percentage of reduction will not be large. But if we think in this way -- that we have removed 53KB of garbage data from the pak file -- this cleaning up is still worthwhile. Quote Selected
Re: [patch] Minor improvements to image writer and reader Reply #10 – February 23, 2010, 11:15:27 am Quote from: wlindley – on January 31, 2010, 06:54:12 pmIt looks like TileCutter (does that use the standard writer code?) can produce many identical 'squares' -- particularly blank ones, or when parts of a large image repeat in the various rotations. Any thoughts on whether checking and re-using identical picture segments would be worthwhile in terms of space?TileCutter doesn't make .pak files directly, but rather uses Makeobj to achieve this, so any optimisations made in Makeobj will apply equally to TileCutter-produced buildings (TileCutter doesn't attempt to optimise its image output for exactly this reason). Quote Selected