I am cognizant of the limitations of my system (an aging low-powered win10 laptop). I tend to keep my PlayRaw and exercise workflow lean, making sure that I break commands and operations down into manageable chunks, especially when the input image is large. To do that, I usually save intermediary files and make sure that I don’t add too many images in the buffer.
(I am still learning how to use
fill to do things, e.g., without using buffer space, and doing more complex calculations in one go. I know we have addressed that before but I still don’t get it. I might write more about that later in this thread.)
Which brings me to the question: is there a way to be kinder to my machine? I know G’MIC has options for Multi-threaded and in-place evaluation, etc., but I would like concrete examples. I also know that ImageMagick, e.g., has memory and processing management parameters and settings, not all of which could be configured post-build. I bet G’MIC (and CIMG) has some neat tricks too. Please share your ideas.
What happens when G’MIC is doing too much on my laptop:
1. Stops operation and says that there is not enough memory. The best outcome.
2. Makes everything else on my system stutter, stall or crash. Usually, it is the first but the second makes my rad tunes stutter and stall; and the latter has happened at least to a Java app. Don’t ask me why I would use that. I understand that many apps think they need to suck up all of the resources; I am looking at you Firefox! So, it is not necessarily G’MIC’s fault.
3. Today, I encountered an error:
terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc
when I mistakenly used
search_dichotomic on two (tiny) images instead of one, without a
repeat $! l[$>]…
endl done. I guess the buffer overloaded due to having too many images being added to the process but not enough being removed. Makes sense that there would be an error; however, it would be nice if there were a message to indicate what happened.
Speaking of error messages, it isn’t a big deal but the error messages for native and non-native files are different when they don’t exist. Maybe I am just slow or tired but it usually takes me several seconds to parse
*** Error *** gmic::fopen(): Failed to open file 'a.gmz' with mode 'rb'. even though I know what it means, whereas
Unknown command or filename… is much easier read.
>gmic a.gmz [gmic]-0./ Start G'MIC interpreter. [gmic]-0./ Input file 'a.gmz' at position 0 [gmic]-0./ *** Error *** gmic::fopen(): Failed to open file 'a.gmz' with mode 'rb'. >gmic a.png [gmic]-0./ Start G'MIC interpreter. [gmic]-0./ Input file 'a.png' at position 0 [gmic]-0./ *** Error *** Unknown command or filename 'a.png' (did you mean 'and' ?).