Other applications could run fine because it only needed 254MB of memory whereas for one case, PIL consumed 13GB of memory / swap. ImageMagick handled the large images gracefully by caching the image pixels to disk rather than memory as expected. The problem with that is, as the images got large (24000x18000, 48000x32000, etc), PIL consumed all the available memory and swap, the system thrashed, became unresponsive, and eventually the PIL slowed to a crawl and the system halted. PIL holds as much of the image in memory (including swap) to take advantage of the fast swapping algorithms handled by the kernel. The cause is that non-intergral rotation does not read from disk sequentially and random disk access is very slow as compared to memory. Smaller images, such as the standard HDTV image format of 1920x1080 rotates in a reasonable time. Its not- except for non-integral rotation which as mentioned uses the 3 pass Paeth shearing algorithm which has been proven to be slow when image pixels are cached to disk. Just a few to see if ImageMagick was outside the performance norm as compared to PIL. Magick wrote:Our benchmarks are not comprehensive. ![]() Each program has its advantages and disadvantages, each is useful depending on the requirements of the problem. The problem with that is, as the images got large (24000x18000, 48000x32000, etc), PIL consumed all the available memory and swap, the system thrashed, became unresponsive, and eventually the PIL slowed to a crawl, the system halted and we had to reboot. Is this my fault (wrong using of convert, wrong provision of resources) or is the rotating algorithm in comparison to other tools so slow? Twice as long as on a windows system with 1 cpu and IrfanView. Just now I have tested it on a 16 CPU unix cluster:Ĭonvert uses 16 CPUs and 4 GB memory! And the time is: 30 seconds. My question again: What is the problem with rotate and huge images? Can someone, who understands the workings (and the memory concept) of this program, give me a concrete hint? If I include this parameter, I wait hours with Mac OS. Loading (decompressing) and Saving (compressing) ist NOT the problem. For example IrfanView needs 0.9 s (874 milliseconds) to load and show this image! (Rotating: 14 s, Saving 4 s) Today I am here on a Window system (Dektop PC with 3 GHz). I think this depends on the cleverness and the algorithms of the programm. But when read in and decompressed it goes to 12,000 x 9,000 x4(channels rgba) = 432 MBytes It took minutes to even open in Mac PREVIEW and GraphicConverter for me. And then takes quite some time to write the image.įmw42 wrote:You file is a compressed PNG of size 540 KBytes. If you watch, you will see the monitor show that it stops at times to write to disk as it read and decompresses the image. So your whole image would barely fit and not allow any room for other code for processing. This is on my G4 Mac Mini PowerPC (one processor) OSX Tiger with only 512 MBytes of memory. Time convert -monitor flat.png -quality 25 flat_tst1.jpg You can see how it progresses by adding -monitor to your command and time it by using time. You need to recompress the output before saving. However, I will defer to the IM developers to explain in more detail or correct me.Īlso much of the time is spent reading and writing the output, especially the output as it is now writing 432 MBytes. ![]() This is a memory issue and depends upon your system and IM how much memory it allows you to use before paging to disk (as I understand it). ![]() It took minutes to even open in Mac PREVIEW and GraphicConverter for me. But when read in and decompressed it goes to 12,000 x 9,000 x4(channels rgba) = 432 MBytes ![]() You file is a compressed PNG of size 540 KBytes.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |