![]() ![]() In that way, the overall memory was again too high and the jobs failed. Thus each of them allocated memory for itself. However Iĭidn't notice that all the jobs started concurrently (not sequentially) and Portions of the same image by translating the same crop window. In this way I defined many jobs on different I did this : I set a window for crop and I repeated "enlarge & save"it forĭifferent part of the picture. You are right, the size of source may be negleted. This would mean that huge images can only be saved as TIFF. Maybe you could tell me your desired zoom, and the output width & height ofįor programming the support for huge output, I will probably concentrate on Impression that this is not the case, maybe there is a bug. A small crop shouldĬompute well even at huge zoom factors and a 10MPixel input. The memory usageĭepends mainly on the dimensions of the output image. SmillaEnlarger ( only the memory usage of the source ). Image to 4 pieces beforehand or crop a quarter from the original within It should make no big difference if you split the ( 10MPixel source image and a 2GB computer ). Your case the size of the source can be neglected It is true that the entire source image is held in memory. Pieces), and SmillaEnlarger would not give error when working on large images. Lot of manual operations (especially to divide the images into 4 equal Using other software, or to use them as they are. In this way 4 enlarged images will be produced (4 pieces should be enough toĮnlarge 10-15 Mpixel photos) and the user will be able to eventually join them Perform enlarge on each of the 4 cropped images, one at a time, saving the results in different files. Perform a automatic crop, to divide the image into 4 equal pieces, each of them half of width and half of height of the initial image and save the cropped images into a temporary file.ģ. (mostly already available in SmillaEnlarger):ġ. My suggestion would be: it would be possible to perform these operations SmillaEnlarger actually already makes Crop, however enlarging fails evenĪpplying crop (on large pictures) because the entire picture is always stored I get memory error when I try to enlarge pictures taken from a 10MpixelĬamera, but I can avoid that if I split the original picture into 4 smaller New functions with new graphic libraries. Maybe a very simple work-around can be implemented, simpler than to implement Your spare time for free to develop this great application. SmillaEnlarger is an open source project, and that means you are giving us ![]() Opensource library to manage large images you can find it here: ![]() Someone (more expert than me) ibn a forum suggested GDAL as one of the best For instance, GEGL, libtiff (which support pyramidal Probably different open source library that manages images by tiles should Large pictures, because probably Qt use lot of memory to extract a portion However this can only partially solve the problem of memory allocation on MainImage=new QGraphicsPixmapItem(QPixmap::fromImage(testimage)) QImageReader testing("mapping/worldmed.tif","tiff") I've read someone suggested QImageReader::setClipRect() to access a portion ofĪn image (and maybe you're already using it.), for instance in this short I'm not an expert about graphics library, but it seems Qt is not very memory-Įfficient to manage large images, so this can be an issue for SmillaEnlarger. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |