|
From: | Thomas L. Scofield |
Subject: | Re: image formats |
Date: | Fri, 8 Aug 2008 15:24:19 -0400 |
On Aug 8, 2008, at 10:41 AM, John W. Eaton wrote:
Agreed.
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?
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.
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 Thomas L. Scofield -------------------------------------------------------- Associate Professor Department of Mathematics and Statistics Calvin College -------------------------------------------------------- |
[Prev in Thread] | Current Thread | [Next in Thread] |