octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MagickLib requirement


From: Carnë Draug
Subject: Re: MagickLib requirement
Date: Mon, 2 Sep 2013 03:08:57 +0100

On 1 September 2013 21:12, Daniel J Sebald <address@hidden> wrote:
> On 09/01/2013 01:39 PM, Carnė Draug wrote:
>>
>> 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?
>
> [snip]
>>
>> [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
>
>
> I'm not sure how up-to-date reference [3] is.

Reference 3 was not meant as a way to solve the problem, only has a
proof that there's mention of it existing since at least that time.

> Anyway, I've tried building
> the latest stable ImageMagick, but it requires a more recent version of
> autoconf than I have.  I could try updating, but I thought I'd see how this
> is supposed to behave first.
>
> How new does a feature need to be?  I suppose a part of the answer depends
> on how critical the feature is and how pervasive the latest versions of the
> related software are in distribution bundles.  I'm not real familiar with
> the particular compression formats.  Are there big demands for JBIG1, JBIG2,
> JPEG2000 and LZMA?  LZMA is an offshoot of Lempel-Ziv I'm guessing, and the
> others sound like some variation of JPEG or some evolutionary fossils of
> JPEG perhaps.

I don't think there isn't much. As far as I know, with the exception
of jpeg200, none is a feature in Matlab but I don't think that's a
reason to drop them. Anyway, removing this piece of code only changes
imfinfo being able to report the correct compression type. imwrite and
imread will still be able to read or write those formats provided that
their graphicsmagick build allows for it (though users won't be able
to change the compression type in formats that allow it which is not
implemented in our side anyway).

Carnë


reply via email to

[Prev in Thread] Current Thread [Next in Thread]