Hallo sunyinan, We uses OO to produce over 6.000 full color magazine pages a year and have over the years encounterd the l"graphic limits" of OO, so i permited me to gives some comments on your analisys > Hi All, > Yes, as Sven said, we should profile the presentation at first. It is the > most right way to improve the performance. > And I also agree that the original image should better be kept. > > But let's think about this thing: > OO is not a professional software of image processing. What we should do > is to make the customers thinking the images quality is well when printing, > presenting and showing etc. They aren't interesting of whether the image is > scaled or what size it should be, are they? In which condition should we > must use the original pixels to do something? > > Let's think about the necessity and feasibility of descaling image which > could be saved in document. > > I have tested some images in my computer, I found that the presenting > speed is not depended on the size of image file but on the resolution "Resolution" is a imaginary thing, its a simple "note" in the file header saying how many pixels the device (screen, printer...) should use to make the picture. For speed Its always the size who matters. So keep the size in proportion to the device. When starting a Presentation the user should be asked for its purpose: on Screen, for Printing ? In the graphic industry we still uses some simple rules who are more based on experiences than one hard facts. For a screen its simple for every screen "dot" we need 1 pixel. For best qualiityy screens and beamers it was 72 but recently 96 pixels per inch is saver For color "laser" and "inkttjet" printing we need 150 pixels/inch for High quality Offset printing we need 250-300 pixels/inch
I think 99% off all presentations are shown on Screen, Beamer and printed with a laser printer. Speed counts only when show on a Screen wath means that we need only a resolution of 96 pixels/inch but this wil gives poor quality when printed. I propose to keep a 150 pixels/inc for the original image stored in the document and use a different "rendering" for Screen and Printing. I do not now how this "rendering" can been done but for website development its a well known technique to store the pictures at a max-resolution on the server and to "deliver" only the asked number of pixels on the screen. Hope it helps Fernand > of it. For example, I saved an original JPEG image(2304*1728, 371KB) to > different formats, such as BMP, TIFF, PNG. The sizes of them are > 15.1MB,18.6MB and 2.42MB accordingly. It spends almost same time to present > them. If the image has 1152*864 pixles with 10MB, the time is 75% of the > original. The less resolution, the faster drawing. > So I think decreasing the resolution can increase the speed of > presentation. > > And let's see how Microsoft PowerPoint do it. I insert the above JPEG > image with the original rect set by MS and saved as 1.ppt. 2.ppt has the same > image with the 1/4 rect of 1.ppt. Decompress these files to packages with XML > files, we can see that in the 1.ppt the saved JPEG image has the original > size and resolution(2304*1728, 371KB) but in 2.ppt, which has 1100*825 > resolution and 169KB size while keeping JPEG formation. If the 2.ppt is > copyed to another computer, the user can not get the original image again. > Does this example prove that MS also don't keep the original files? I think > so. > > So, I think descaling the image not only can improve presenting > performance but is a feasible way. > > Basing on this, our test-department colleagues tested the displaying > impact of downscaled image in printing, presenting, projecting and showing in > PC and MID(Mobile Internet Device). What we used devices are HP LaserJet 1020 > with FastRes 1200(higher than 600 dpi), SANYO PLC-XW6680CA projector and SONY > VPL-CX6 projector, and the MID has 1GHz CPU with 512MB DDR2 memory and 7" > LCD with 800*600 resolution. We set the threshold is 1000 pixel for column > and row. The original image is scaled to that whose column or row has less > than 1000 pixels, such as 2304*1728 to 1152* 864. We tested several images > with different formations. Compared with no-downscaled image, the impact has > not the obvious difference and the speed is increased especially for MID. > > In conclusion, I think descaling the resolution of image is an acceptable > way to improve performance with no-decreased impact and we need not hold the > original image in our files. > > If you agree with it, I think the next step is to find how and where to > descale the high-res image. Maybe we can provide an option to let the user > deciding whether saving the original size or not when he saving a file. > > > 2009-01-12 > > > > sunyinan > > > > 发件人： Sven Jacobi > 发送时间： 2008-11-27 01:23:31 > 收件人： [email protected] > 抄送： > 主题： Re: [graphics-dev] [Impress] Information about improvingperformance > > Christian Lippka - Sun Microsystems GmbH - Hamburg wrote: > >> Hi All, >> >> I personally do not like to scale down images that the user wants to >> embed in the document. I have not >> checked it yet but I believe if Microsoft does it they only do it as a >> cache for non embedded images. >> I'm pretty sure that we will get flames from users if they print their >> documents and the images have >> data loss. >> On the other hand, I think that Sven Jacoby already implemented >> something that loads pictures in a >> smaller size. That was needed to optimize rendering of the preview >> images for slides. Maybe this can >> also be used for speeding up the presentation? I cc'ed him so he >> hopefully will comment on this. >> >> Regards, >> Christian >> >> > We are able to load jpeg graphics faster by leaving out scanlines and we > also take > care of the png progressive mode when loading preview graphics but this > mechanism > is no solution. Leaving out scanlines is no proper downscale method and > will result > in a bad image quality. > I think before starting a discussion on how to improve the performance, > the presentation > should be profiled so that we have some numbers we can deal with. > Regards, > Sven > >> Thorsten Behrens wrote: >> >>> On Tue, Nov 25, 2008 at 02:01:02PM +0800, sunyinan wrote: >>> >>> >>>> As for a fast scaler, I think there must be two for-loops to >>>> extract the pixels from lines and columns. So from this, it is hard >>>> to be faster. >>>> >>>> >>>> >>> Hi sunyinan, >>> >>> well, the referenced bmpfast.cxx does speed things up, e.g. by >>> taking one scanline at a time. But you won't get orders of magnitude >>> with this, that's true. >>> >>> >>> >>>> So I think scaling image when decoding is an acceptable way even >>>> it slows down the inserting speed. What do you think about it? >>>> >>>> >>> I don't like that, at least not if it's done unconditionally. Better >>> make that an option, and better still, do both - keep the original >>> file, and have a low-res "preview" bitmap along with it, maybe even >>> stored on disk. >>> >>> >>> >>>> Another question is that GDI+ is used to "slide show" the presentatio >>>> while GDI to the presentation. As we all know, GDI+ is slower than GDI >>>> ( if DrawImage method is repleased by bitblt, the speed is more fast >>>> than now). So, why don't we also use GDI for "Slide show"? >>>> >>>> >>>> >>> Because GDI doesn't do antialiasing. But feel free to replace the >>> DrawImage call with a GDI method, the difference in quality is >>> usually not too big for pictures. >>> >>> >> Well we already have an issue with some votes that Impress does not >> scale images as >> nice as PowerPoint does, so I would not count on this. >> >> Regards, >> Christian >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
