Dropping octave's native image format

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dropping octave's native image format

Carnë Draug
Hi

one thing that I never knew about was Octave's native image format.
Basically, this "image format" is any file that can be read with
load() and contains 1 or 2 variables, depending if it's an indexed
image. If it's an indexed image, the two variables must be named "X"
and "map" (the indexed image, and the colormap) otherwise it must have
a variable named "img".

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).

Carnë
Reply | Threaded
Open this post in threaded view
|

Re: Dropping octave's native image format

Søren Hauberg
On Jul 13, 2013, at 3:24 AM, Carnë Draug <[hidden email]> 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.

Søren
Reply | Threaded
Open this post in threaded view
|

Re: Dropping octave's native image format

Rik-4
In reply to this post by Carnë Draug
On 07/13/2013 09:04 AM, [hidden email] wrote:

> Message: 2
> Date: Sat, 13 Jul 2013 11:11:46 +0200
> From: S?ren Hauberg <[hidden email]>
> To: Carn? Draug <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Dropping octave's native image format
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Jul 13, 2013, at 3:24 AM, Carn? Draug <[hidden email]> 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.
>
> S?ren
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.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: Dropping octave's native image format

Carnë Draug
On 13 July 2013 22:11, Rik <[hidden email]> wrote:

> On 07/13/2013 09:04 AM, [hidden email] wrote:
>> Message: 2
>> Date: Sat, 13 Jul 2013 11:11:46 +0200
>> From: S?ren Hauberg <[hidden email]>
>> To: Carn? Draug <[hidden email]>
>>
>> On Jul 13, 2013, at 3:24 AM, Carn? Draug <[hidden email]> 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ë