Re: image formats

[John W. Eaton]

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