Re: Dropping octave's native image format

[Carnë Draug]

On 13 July 2013 22:11, Rik <address@hidden> wrote:
> On 07/13/2013 09:04 AM, address@hidden wrote:
>> Message: 2
>> Date: Sat, 13 Jul 2013 11:11:46 +0200
>> From: S?ren Hauberg <address@hidden>
>> To: Carn? Draug <address@hidden>
>>
>> On Jul 13, 2013, at 3:24 AM, Carn? Draug <address@hidden> wrote:
>>> > This is what I figured by reading the source of imread. As far as can
>>> > see, this format is completely undocumented, and we don't even have a
>>> > function to write into it. Should we remove this? I'm guessing that
>>> > even if we removed it, no one would notice (except for when calling
>>> > image() without arguments since it loads default.img, the only example
>>> > I have of an image in this format).
>> This is from back before Octave had 'imread' and 'imwrite'. Then we had the 
>> functions 'loadimage' and 'saveimage' .
>>
>> Is there any maintenance burden in supporting this old format? I guess it is 
>> quite unused, but if it doesn't hurt to keep supporting it, then I don't see 
>> a reason to remove it. If it makes it harder to evolve the code to support 
>> this, then I think it's fine to drop it.
>>
> I would take the code out.  The functions loadimage and saveimage were
> removed before 3.6 so there's no good way to access this data type.
>
> I think it is sort of like your appendix which is generally fine to have
> around until, on the odd occasion, it gets inflames, bursts, and puts you
> in the hospital.  In this case we could leave the appendix code in place,
> but one day it might burst.  And leaving it in I think will also be
> confusing to anyone else who stumbles over this code at a later date.  Only
> someone like Soren, with a long history with Octave, had any clue what this
> was supposed to do.

The only reason I know what the code does is because one the error
messages says "octave image format". Other than that, there isn't even
a comment on the code about what it is going on.

I do see a small advantage with this format, which is not requiring
GraphicsMagick. But someone wanting to do image processing should have
that library around, and they don't, they might as well use load and
save directly. And the next version of Octave will have imformats
which would allow someone to bring back and expand the format in a way
that it works with imread, imwrite, and imfinfo.

And there's plenty of image formats around, I don't think we should be
inventing yet another one.

Carnë