Re: image formats

On Aug 8, 2008, at 10:41 AM, John W. Eaton wrote:

On 8-Aug-2008, Thomas L. Scofield wrote:

| I can think of two reasons, though I'm not going to try to argue that
| either one is very strong. The first is you need some sort of
| internal list to appeal to if there is to be an imformats command.

I wasn't aware of the imformats command until now, but I suspect that
before too long, someone will complain that it is missing. So since
we are writing this now, we might as well consider implementing
something that allows for a compatible imformats function.

| The second is that some formats have "options" one would want to
| employ---for instance, setting the quality for a jpeg image.
| Matlab's documentation spells out the various options it supports for
| the formats it offers, and to mimick them all (if that's a goal) will
| be tedious---I'm not necessarily intending to do so.

I think we can have a list of options that go with certain formats
without also making that list be a limit what is possible.

Agreed.

| Later users who
| come along and find they can write to some more exotic format X will
| perhaps wonder why they have to accept default options (i.e., not
| allowed to specify their own). But, to be fair, my guess is that the
| number of requests/complaints arising this way will be few. And,
| there is always the "you want it, you write it" response.

Here are some thoughts:

* The imformats function returns a structure that contains handles
to the functions that do the actual reading, writing, and
identification of each image format. Splitting up the code this
way might be a nice way to organize the code, so that we don't
have one giant function that tries to do everything.

* We could allow the list of known image types to be extensible by
doing something like this

function [...] imformats (...)
format_struct = __imformats__ ("get", ...);
...
endfunction

function format_struct = __imformats__ (action, ...)
persistent format_info;
if (isempty (format_info))
... set defaults ...
endif
if (strcmp (action, "get"))
format_struct = fmt_info;
elseif (strcmp (action, "set"))
... add to format_info ...
else
error (...);
endif
endfunction

Do "persistent" variables have values that survive from one run of Octave to another? Oh, from your next comment I think I get it. Somehow the inclusion of a handler for .widge image files involves, at Octave start-up, a write to the persistent variable format_info, right?

Then people adding image format handlers could make calls to
__imformats__ in their PKG_ADD files to install new format
information.

I'm proposing two functions here so that we don't alter the
imformats interface and possibly cause later compatibility
problems.

* There could be a catch-all case that handles no special options
and simply uses the __magick_read__ and __magick_write__
functions to try to read or write the format. This could be used
if no other format matches.

Perhaps I'll change my mind on this the further I get into __magick_write__, but I'm currently thinking that all cases should be passed through the two __magick_xs__. So much is handled correctly automatically by imread, I see most forking happening in imwrite, and think it should happen mid-process. As far as I can tell, forking happens based on the following:

- bitmapped vs. indexed image

- single image vs. image sequence

- image class (logical, uint8, etc.)

- formatting options

Of these, only the last is closely tied to the actual image format, and even there it is not a direct link: 'Quality' my be an option tied closely to jpeg, but 'Description' is something supported in Matlab for multiple formats. (By this I do not mean to imply that, say, image sequences are supported in numerous formats, but rather that the calls to GraphicsMagick library functions are the same across formats.)

Anyway, I don't hear you saying it has to be such-and-so, but rather that ease of extensibility should be a guiding principle.

So, I'll try to put something together that, once the Magick::Image variable has been put together from the input matrix, checks both the format and option list and makes calls to separate functions to process the options.

I'm somewhat confused about where calls of type

__imformats__ ("set", ...)

appear, however.

* It seems that Matlab allows writing image files to files with
arbitrary names. For example, I think

imwrite (x, 'foo', 'jpg')

or even

imwrite (x, 'foo.png', 'jpg')

is possible and writes an image in the jpeg format to a file
without a ".jpg" extension (or even to a file with a ".png"
extension; not that you would normally want to do this, but
I think it is possbile). Is there a way to get GraphicsMagick to
do this? If not, then we may need to write the data to a tmp file
and then rename. I don't think this feature should have a high
priority, but it is something to keep in mind.

jwe

From:	Thomas L. Scofield
Subject:	Re: image formats
Date:	Fri, 8 Aug 2008 15:24:19 -0400