Re: image formats

[John W. Eaton]

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