#320 Setting image (x,y) pixel coordinates doesn't.

open
nobody
None
5
2012-03-09
2012-01-22
Craig DeForest
No

v4.4+ supports images, but accepts 3-typles (x,y,value) while essentially ignoring the (x,y) part. The documentation indicates that "It is assumed that in the viewing plane the image data forms an equidistant sampling grid in the viewing plane along two, not necessarily orthogonal, directions.". If making such a drastic assumption, it doesn't make sense to accept the full (x,y) column values at all -- for a 2k x 2k image with a 3-tuple, the pixel shape information is oversampled by a factor of 2 million.

Clearly this needs attention for the future. I came across this particular bug because, while working on the new PDL::Graphics::Gnuplot interface module to PDL (http://pdl.perl.org), I wanted to adapt the FITS WCS display system that is currently used with PGPLOT. WCS is the "World Coordinate System", and it follows a particular standard for communicating how scientific image coordinates (e.g. "arcseconds" in a telescope image plane or "meters" on a map) map to pixel coordinates. PGPLOT uses the parallelogram assumption as does Gnuplot, but allows the user to send a transform matrix rather than laboriously enumerating the (ignored) position of every pixel. Contrariwise, allowing fully general grid layout (subject to the usual caveats that stupid grids will probably yield stupid results) would allow fully general nonlinear transformations of images without pre-render resampling, which would be a big win.

Discussion

  • Ethan Merritt
    Ethan Merritt
    2012-01-22

    I'm not quite following your description of the WCS format, but would be happy to review any contributed patch to gnuplot so that it can be read in directly. For example there are already input modes for images in edf and png formats. There is also the option to read in a transformed image via a filter program.

    Having said that, I think it is possible to apply the transformation you want using gnuplot's existing syntax for matrix input. It is not true that the input file must contain 3-tuples; in fact most of the input modes for matrix data (including images) assume that only the pixel values are present. Have a look at the "heat map" demos, for example. It is also possible that the demos in http://gnuplot.sourceforge.net/demo_cvs/image2.html are relevant, although I'm not sure. They show how you can reorient the image grid in 3D so that the head-on view in 2D is skewed in various ways. This may or may not cover your use case.

     
  • Craig DeForest
    Craig DeForest
    2012-01-25

    Thanks. The WCS is just a collection of keyword/value pairs that describe how to map a scientific coordinate system to/from the pixel grid coordinates. They are used inside another scientific image standard ("FITS") with human-readable ASCII headers and binary data.

    I'm not concerned that the image input *must* accept 3-tuples (as you say, that's not the case) but rather that it *can* accept 3-tuples, but then drops virtually all of the (x,y) data on the floor. I'll search through the "heat map" demos to find an example that at least can do linear transformations, which solves my immediate need -- but I'll leave this open as a marker that (IMAO) even accepting the 3-tuple case is a bug if the tuples aren't used correctly.

     
  • Ethan Merritt
    Ethan Merritt
    2012-03-09

    • labels: 102065 -->
     
  • Ethan Merritt
    Ethan Merritt
    2012-03-09

    Moving this to "feature requests".

    I just can't see this as a bug.
    The pixels in an image lie on a regular grid.
    If you have a non-uniform grid, there are other plot styles that can hangle it. But it isn't an "image". And in fact you can do nonlinear transforms of the grid, so long as the grid itself is regular.