[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: image formats
From: |
John W. Eaton |
Subject: |
Re: image formats |
Date: |
Mon, 11 Aug 2008 13:29:13 -0400 |
On 8-Aug-2008, Thomas L. Scofield wrote:
| > * 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?
No.
| 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?
Yes, the function that handles a new image type could just have a
## PKG_ADD: __imformats__ ("set", ...);
line in it, and the build process will automaticaly put that in the
PKG_ADD file for the directory containing the function .m file.
| > * 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.)
As I see it, the handler functions could ultimately call
__magick_read__ to do the work, and it should also be possible for the
handler function to simply be __magick_read__ if there are no special
options to process for the image type.
|
| 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.
Yes, I think that's an important factor.
| > * 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
| >
|
| As best as I can tell, the Magick++ API specifically prohibits this.
| (Source: boxed example at the top of page 8 in the document found at
| http://www.imagemagick.org/Magick++/tutorial/Magick++_tutorial.pdf)
| There is a C API to GraphicsMagick documented at http://
| www.graphicsmagick.org/www/api.html which I have made no attempt to
| understand but may offer more low-level capability at the expense of
| being more difficult(?) to use. Personally, I cannot think of why
| anyone would want to use an extension that was standard for a
| different format. What does make some sense is the possibility of
| using a file that contains a period but doesn't correspond to any
| usual format:
|
| bridge.indexed
| bridge.bitmap
I'm not saying it is useful to save jpeg data in a file called
foo.png, but arbitrary file names should be possible. So if the
Magick++ API doesn't allow it directly, we will have to save the data
in a tmp file (that uses the "correct" extension) and then rename it.
But again, I would not bother working on that part as it is a minor
and probably not often used feature. It is more important to get the
reading and writing working correctly and in a compatibly way.
Thanks,
jwe