I don't know if this is the right place to post this, but anyway... I have this small octave function, that runs fine on my Windows Octave, but crashes on my fink octave-atlas(3.6.3):
" function simpleImageExample imageFile = "100-0039_IMG.JPG"; info = imfinfo (imageFile) I = imread (imageFile); subplot(2,1,1); imshow(I); endfunction " If I run the function as shown above, octave crashes with this messages " warning: your version of GraphicsMagick limits images to 16 bits per pixel octave(18942,0x10b2db180) malloc: *** error for object 0x10b989570: pointer bei ng freed was not allocated *** set a breakpoint in malloc_error_break to debug panic: Abort trap: 6 -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete " The problem occurs in "imfinfo" because if I remove the line "info = imfinfo (imageFile)" then I only get the warning " >>> simpleImageExample warning: your version of GraphicsMagick limits images to 16 bits per pixel >>> " and the picture looks OK. --Eigil Den 05/02/13 15.01 skrev "Martin Costabel" <costa...@wanadoo.fr>: >On 5/02/13 11:23, Peter Dyballa wrote: >> >> Am 05.02.2013 um 09:27 schrieb Martin Costabel: >> >>> The question is whether the octave programmers misunderstood this only >>>in their warning text or also in the octave code. >> >> Another question also exists: how do Octave and GraphicsMagick >>interchange graphics data? Is it by standard file formats (in memory or >>on disk) or is it via an API? In the first case the differences in pixel >>resolution should not play any role, because *standard* (external) data >>formats are used. (PNG is PNG, no matter if it's 1 bit or 64 bit deep. >>Each such object is identifying itself by a header, so writer and reader >>have the exact knowledge of the object and GraphicsMagick and also >>Octave can use internally whatever format it wishes or prefers to use >>for its own private working representation of the external graphics >>object.) If the data exchange works via APIs then both users of this API >>might have to stick to some agreed upon value if there's no way to >>negotiate via the API this value. > >The warning in question comes from the file >src/DLD-FUNCTIONS/__magick_read__.cc in the octave code. This seems to >be the code that implements the interface with GraphicsMagick, and it >uses functions from libGraphicsMagick++. So the interface is by API, and >it is to be hoped that this is used correctly. In this case, the warning >should simply be ignored. > >-- >Martin > > ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
