Re: MagickLib requirement

[Carnë Draug]

On 1 September 2013 10:47, c. <address@hidden> wrote:
>
> On 1 Sep 2013, at 10:40, Daniel J Sebald <address@hidden> wrote:
>
>> Carnë,
>>
>> With the following changeset:
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/ba79ba4e83ab
>>
>> my version of tools is just a little too old so that I get the following 
>> erros:
>>
>> ../../octave/libinterp/dldfcn/__magick_read__.cc: In function 'octave_value 
>> magick_to_octave_value(const MagickLib::CompressionType&)':
>> ../../octave/libinterp/dldfcn/__magick_read__.cc:1484:12: error: 
>> 'LZMACompression' is not a member of 'Magick'
>> ../../octave/libinterp/dldfcn/__magick_read__.cc:1486:12: error: 
>> 'JPEG2000Compression' is not a member of 'Magick'
>> ../../octave/libinterp/dldfcn/__magick_read__.cc:1488:12: error: 
>> 'JBIG1Compression' is not a member of 'Magick'
>> ../../octave/libinterp/dldfcn/__magick_read__.cc:1490:12: error: 
>> 'JBIG2Compression' is not a member of 'Magick'
>>
>> Is Octave meant to be compilable with older versions of ImageMagick library? 
>>  I.e., create some functions like
>>
>> #if IMAGEMAGICVERSION < 6.6.??
>> void LZMACompression ()
>> {
>>  error ("Requires ImageMagick version 6.??.?? or higher");
>> }
>> void JPEG2000Compression ()
>> {
>>  error ("Requires ImageMagick version 6.??.?? or higher");
>> }
>> etc.
>> #endif
>>
>> Or is the expectation that ImageMagick should just be up to near the most 
>> recent version?

We can't check for versions since that would not allow to be built
with GraphicsMagick which uses different version numbers. Also, is
that the correct version number required by ImageMagick? I downloaded
ImageMagick (I've been using GraphicsMagick) to find the right number
but their NEWS file only says "No news is good news.". Their ChangeLog
goes down to 2007 and from those types, only mentions LZMACompression
which was added in 2010-12-17 (not sure about the release date). This
would suggest that the others are more likely disabled features (see
the comment on the bug report for this[1] and reply there).

I have googled for them anyway and found at least this post [2] from
August 2010 reporting about it. Also, their list of constants [3]
mentions version numbers for some of them, as early as 6.9.3 which was
released in 2008. This would suggest they were released before that.
How new does a feature needs to be to require a test?

Isn't it bad enough that people with different quantum builds will
read the same image differently?

> Maybe this problem is related to the various bugs being reported that 
> currently prevent image processing functions? e.g.:
>
> https://savannah.gnu.org/bugs/?39698
> https://savannah.gnu.org/bugs/?39761

These two bugs are the same thing. It would appear it's caused by
something in __magick_imfinfo__ but it appeared before I did anything
on it. And I can't replicate it. Does anyone not on Mac has this
problem? Also, do they still occur while reading an actual png file?
The test in imread is reading a png file written with fwrite.

> https://savannah.gnu.org/bugs/?39913

This problem is not related with that bug. This problem is what is
reported in that bug.

> Carnë, do you think that updating GraphicsMagick might help avoiding these 
> issues? I've been building with GraphicsMagick disabled
> lately but I'll need to work with images in the next few weeks ...

I don't know about fixing the failing test with imread (can you please
try?), but it will certainly fix the issue with this other bug which
is a feature that was released with GraphicsMagick 1.3.13 (released
December 24, 2011) and ImageMagick 6.6.6-6.

Carnë

[1] https://savannah.gnu.org/bugs/?39913
[2] http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=16800
[3] http://www.imagemagick.org/RMagick/doc/constants.html#CompressionType