[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: image formats
From: |
John W. Eaton |
Subject: |
Re: image formats |
Date: |
Fri, 08 Aug 2008 10:41:08 -0400 |
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.
| 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
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.
* 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