Re: reuse image.display() window?

The co-process idea wont work for my situation, but thanks very much for 
looking into it.
I'll try to remember to update this thread if I come up with a solution 
worth sharing.
Thanks again!


On 11/28/17 09:20, Bob Friesenhahn wrote:
> On Mon, 27 Nov 2017, Robert H. Olsen wrote:
>
>>
>> Is there a way to use GraphicsMagick to display an Image, but somehow 
>> retain control of the display window so that subsequent images can be 
>> displayed in the same window?
>>
>> For example, if I have images being acquired at, say, 1 hz is there 
>> some way that I can overwrite/replace the older image in the same 
>> window when a new one arrives using GraphicsMagick?
>>
>> The display() function for an image object works fine for a single 
>> image, but the user must close the window.
>>
>> I found references to functions like MagickXPasteImage in display.h 
>> but couldn't determine if that might be useful to me, or how that 
>> might be used.
>
> It is likely that the necessary code exists but it might not be 
> accessible.
>
> A ready-made way to accomplish this is by using the 'gm display' 
> utility as a co-process.
>
> Start 'gm display' as a background process (gm display &). Then run
>
>   gm display -remote filename
>
> to cause the displayed image to be reloaded based on filename 
> (unfortunately requires that a file be written).  This command will 
> return as soon as the request has been sent.  This is using X11 for 
> the communication to send the command.  As a result, there can only be 
> one such window per X11 server unless perhaps via some X11-specific 
> mechanism.
>
> If you don't want a progress indicator while the image is loading, 
> then start the background process like
>
>   gm display +progress &
>
> If your images were all 512x512 then you could do
>
>   gm display +progress -size 512x512 xc:black &
>
> and then the initial image would be a black window which is replaced 
> with the first image which is loaded.  As an alternative, you could 
> start the background program with your first image file and then 
> reload it after that.
>
> If you are creating a slide-show, then it is important not to send 
> update requests faster than the image can reasonably be displayed.  I 
> don't know if 1 HZ rates are possible, but it would depend on the 
> dimensions of your image and the intermediate format used.
>
> The functionality of 'gm command' is available in the GraphicsMagick 
> library.  There are prototypes for 'GMCommand()' (any GraphicsMagick 
> utility command) and 'DisplayImageCommand()' declared in 
> magick/command.h.  This means it is possible to avoid executing an 
> external 'gm' utility (particularly to refresh the image) but the 
> program which displays the image still needs to be a co-process.
>
> Bob


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot