image formats

Fri Aug 8 14:24:19 CDT 2008

On Aug 8, 2008, at 10:41 AM, John W. Eaton wrote:

> 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.
>

Agreed.

> | 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
>

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?

>     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.
>

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.

>   * 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

Thomas L. Scofield
--------------------------------------------------------
Associate Professor
Department of Mathematics and Statistics
Calvin College
--------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080808/df675b05/attachment-0001.html 