Re: Problems combining new v7.0 Image command with other graphics
- To: mathgroup at smc.vnet.net
- Subject: [mg95108] Re: Problems combining new v7.0 Image command with other graphics
- From: Jens-Peer Kuska <kuska at informatik.uni-leipzig.de>
- Date: Wed, 7 Jan 2009 04:04:42 -0500 (EST)
- Organization: Uni Leipzig
- References: <gjv732$ov0$1@smc.vnet.net>
- Reply-to: kuska at informatik.uni-leipzig.de
Hi,
Graphics[Raster[]] ist still working in V 7.0 and it is used
by Mathematica 7.0 in the LineIntegralConvolutionPlot[],
all Image*[] functions accept Graphics[Raster[]], so
ImageData[Graphics[Raster[bm_,___],___]] will return bm.
This should solve 1) and 3)
To store arbitrary values, you can use Image[] with floating point
values. As long as you don't use ImageAdjust[] everything (except the
display) will work. In the distance transform Mathematica make exact
this, it return the distance map as an image, with the correct distance
values and suggest "if you wish to see the distance map use ImageAdjust[]".
For 2) the normal way is to use masks, i.e. binary images
that indicate the region where the operation should be done.
You can do that with
WorkOnlyOnMask[mask*image]*mask+ Invert[mask]*image
That is common in more interactive applications like Corel PhotoPaint
or Photoshop. In scientific image processing is is less often used
because nobody need to keep the background intact.
Regards
Jens
Mac wrote:
> The new image processing features of Mathematica are very useful and
> very much needed at least for my work. There are, however, three key
> features that are missing in my opinion or are implemented in an
> inconsistent fashion:
>
> 1) The ability to manipulate image data that is not scaled between 0
> and 1. In many cases image data represent useful physical information
> (e.g. brightness of stars, temperature etc...) which are usually
> encoded in reals. Scaling everything between 0 and 1 to be able apply
> the image processing routines like ImageCrop[], ImageTake[] and
> ImagePartition[] seems clumsy and unnecessary. My previous experience
> with the IDL language didn't require jumping through these kind of
> hoops. Note that the Raster[] command does give the possibility of
> scaling data on the fly for display.
>
> 2) The ability to apply image processing to user defined regions. It
> would be very useful to be able to define regions of interest (say
> with polygons) and apply image processing or information extraction
> techniques to this region only instead of treating the whole image.
>
> 3) Inconsistent behaviour with respect to combined graphics. An
> example is given below illustrating how difficult it is to combine
> Image data with other Mathematica graphics. The fact that the Show[]
> command works with a single image but not with multiple image +
> graphic combinations seems to be inconsistent with the syntax and
> purpose of the Show[] command. Using Raster[] we get the expected
> behaviour but cannot use the new image processing routines of v. 7.0.
>
> If you have any work arounds for the above problems or comments I
> would be interested in hearing these.
>
> Mac
>
> Example:
>
> Generate an small test image
>
> img = RandomReal[{0, 1}, {100, 200}];
>
> This works and produces a graphic in the notebook
>
> Image[img]
>
> This also works
>
> Show[Image[img]]
>
> However, although show works with a single image, showing several
> graphics combined produces the error "Image is not a Graphics
> primitive" even though the Show[] syntax is respected.
>
> Show[Image[img, ImageSize -> 200], Graphics@Circle[]]
>
> This also produces a the same error
>
> Graphics@Image[img]
>
> whereas graphics can be combined using the old-fashioned Raster
> command without problem
>
> Show[Graphics@Raster[img], Graphics[{Red, Circle[{100, 50}, 40]}]]
>