On 2/5/13 2:23 PM, Alexander Hansen wrote:
> On 2/5/13 1:52 PM, Eigil Krogh Sorensen wrote:
>>
>> Den 05/02/13 21.03 skrev "Alexander Hansen" <alexanderk.han...@gmail.com>:
>>
>>> On 2/5/13 10:35 AM, Eigil Krogh Sorensen wrote:
>>>> 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
>>>>
>>>>
>>>>
>>>
>>> I can confirm this behavior.
>>>
>>> When I tried a local rebuild of graphicsmagick using
>>> "--with-quantum-depth=32" I still got a "warning: your version of
>>> GraphicsMagick limits images to 16 bits per pixel" message from Octave.
>>>
>>> The malloc() error goes away, but then the behavior gets really strange.
>>> I made up identical test.jpg and test.jpeg files, so one would think
>>> the error messages, if any, would be the same, but instead I get
>>> (10.8/x86_64):
>>>
>>> octave:1> imfinfo ("test.jpeg")
>>> warning: your version of GraphicsMagick limits images to 16 bits per pixel
>>> error: Magick++ exception: Magick: Unable to open file (g) reported by
>>> magick/constitute.c:1533 (ReadImage)
>>> error: called from:
>>> error: /sw/share/octave/3.6.3/m/image/imfinfo.m at line 147, column 10
>>> octave:1> imfinfo ("test.jpg")
>>> error: Magick++ exception: Magick: No decode delegate for this image
>>> format () reported by magick/constitute.c:1522 (ReadImage)
>>> error: called from:
>>> error: /sw/share/octave/3.6.3/m/image/imfinfo.m at line 147, column 10
>>>
>>> When I rebuilt graphicsmagick using "--with-quantum-depth=8" the results
>>> are still wrong, but at least more consistent:
>>>
>>> octave:1> imfinfo ("test.jpeg")
>>> warning: your version of GraphicsMagick limits images to 16 bits per pixel
>>> error: Magick++ exception: Magick: No decode delegate for this image
>>> format () reported by magick/constitute.c:1522 (ReadImage)
>>> error: called from:
>>> error: /sw/share/octave/3.6.3/m/image/imfinfo.m at line 147, column 10
>>> octave:1> imfinfo ("test.jpg")
>>> error: Magick++ exception: Magick: No decode delegate for this image
>>> format () reported by magick/constitute.c:1522 (ReadImage)
>>> error: called from:
>>> error: /sw/share/octave/3.6.3/m/image/imfinfo.m at line 147, column 10
>>>
>>>
>>>
>>> On 10.5/powerpc I get malloc() error messages but the image information
>>> shows up (same test.jpg and test.jpeg):
>>>
>>> octave:2> imfinfo ("test.jpeg")
>>> octave(47725) malloc: *** error for object 0xa08bf708: Non-aligned
>>> pointer being freed
>>> *** set a breakpoint in malloc_error_break to debug
>>> octave(47725) malloc: *** error for object 0xa08bf708: Non-aligned
>>> pointer being freed
>>> *** set a breakpoint in malloc_error_break to debug
>>> ans =
>>>
>>> scalar structure containing the fields:
>>>
>>> Filename = /Users/hansen/test.jpeg
>>> FileModDate = 5-Feb-2013 12:21:54
>>> FileSize = 26699
>>> Height = 241
>>> Width = 241
>>> BitDepth = 8
>>> Format = JPEG
>>> LongFormat = Joint Photographic Experts Group JFIF format
>>> XResolution = 0
>>> YResolution = 0
>>> TotalColors = 68
>>> TileName =
>>> AnimationDelay = 0
>>> AnimationIterations = 0
>>> ByteOrder = undefined
>>> Gamma = 0
>>> Matte = 0
>>> ModulusDepth = 8
>>> Quality = 75
>>> QuantizeColors = 256
>>> ResolutionUnits = undefined
>>> ColorType = grayscale
>>> View =
>>>
>>> octave:3> imfinfo ("test.jpg")
>>> octave(47725) malloc: *** error for object 0xa08bf708: Non-aligned
>>> pointer being freed
>>> *** set a breakpoint in malloc_error_break to debug
>>> octave(47725) malloc: *** error for object 0xa08bf708: Non-aligned
>>> pointer being freed
>>> *** set a breakpoint in malloc_error_break to debug
>>> ans =
>>>
>>> scalar structure containing the fields:
>>>
>>> Filename = /Users/hansen/test.jpg
>>> FileModDate = 5-Feb-2013 12:21:54
>>> FileSize = 26699
>>> Height = 241
>>> Width = 241
>>> BitDepth = 8
>>> Format = JPEG
>>> LongFormat = Joint Photographic Experts Group JFIF format
>>> XResolution = 0
>>> YResolution = 0
>>> TotalColors = 68
>>> TileName =
>>> AnimationDelay = 0
>>> AnimationIterations = 0
>>> ByteOrder = undefined
>>> Gamma = 0
>>> Matte = 0
>>> ModulusDepth = 8
>>> Quality = 75
>>> QuantizeColors = 256
>>> ResolutionUnits = undefined
>>> ColorType = grayscale
>>> View =
>>>
>>> I'll investigate this further.
>>>
>>> --
>>> Alexander Hansen, Ph.D.
>>> Fink User Liaison
>>> My package updates: http://finkakh.wordpress.com/
>>
>> FYI:
>> Did try to rebuild graphicsMagick (and octave-atlas had to be build also)
>> to 32 bits. On my system that din not make the performance noticeably
>> worse.
>>
>> Now I'm back on latest fink versions of GraphicsMagick and octave-atlas
>>
>>
>> --Eigil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> I wouldn't think that you'd need to rebuild octave-atlas. It links to
> graphicsmagick dynamically rather than statically.
>
Ah, but I thought incorrectly. You're quite correct that you need to
rebuild Octave when you change the GraphicsMagick quantum size.
For further tests, I tried Fink's ImageMagick instead of GraphicsMagick,
but I got the same error. And I tried different compilers and
optimizations, but the error persists.
I'm trying 10.6/i386 and 10.6/x86_64 now, to see if the problem is
restricted to 64-bit builds.
--
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/
------------------------------------------------------------------------------
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
