Re: Writing image to blob PNG vs TIFF

Hello Bob

I appreciate the quick reply!

I think I'm probably misunderstanding what you mean by "multiple image 
frames" though?

I'm only interested in dealing with a single image at a time - not, for 
example, making a multiple-image TIFF.  I want to capture an image, 
process it, package it, send it out over the network and then wait for 
another.  And this works fine if I tell Image.write that it's a PNG.  Is 
there some way of saying "this is a new, distinct image" when writing 
TIFF to a blob, other than changing its size? Would toggling between two 
different pBlob memory locations trick it?

Thanks again.


On 12/18/17 12:13, Bob Friesenhahn wrote:
> On Mon, 18 Dec 2017, Robert H. Olsen wrote:
>>
>>   // Create a formatted gm blob
>>   Blob * pBlob = GetPBlob();   // points to space allocated elsewhere
>>   gmimage.write(pBlob, GetGMType());  // GetGMType() returns either 
>> "PNG" or "TIFF"
>> //   gmimage.write(pBlob, "TIFF");
>> //   gmimage.write(pBlob, "PNG");
>>
>> This works well for "PNG" but if the type is "TIFF" then the image at 
>> pBlob is correct only the first time through after starting up or 
>> changing from PNG mode, or if I change the number of times minify() 
>> is run on the image, otherwise the image data is not changed though 
>> it should have been updated when the new trigger was received. If I 
>> switch back to PNG everything is fine again.  Do TIFF and PNG deal 
>> with previously allocated space differently, or something like that?
>
> Due to my decision to use STL containers to support multiple image 
> frames, the Image read/write functions only support a single image frame.
>
> You must use the STL-based interfaces readImages() and writeImages() 
> from Magick++/STL.h to deal with multiple frames.
>
> Please see http://www.graphicsmagick.org/Magick++/STL.html for 
> documentation on how to use the STL-based interfaces.
>
> Unfortunately, this means that some of your code will need to be 
> re-written.
>
> At the C language level, a sequence of image frames is represented by 
> a linked list.  For the C++ interface, these sequences (based on 
> previous/next pointers) are broken (previous/next pointers set to 
> NULL) and the STL container functionality is used to remember the 
> relationship between frames.  When the C++ interface calls into the C 
> interface it must temporarily re-create a linked list of image frames 
> (which it again destroys afterward).  For this reason, you should not 
> use multiple threads on the same STL container.
>
> Bob
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Graphicsmagick-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
>


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