Custom Query (35 matches)

At the moment they just run sequentially, and use the Data.Vector versions. We should really do a parallel tree reduction.

Representing bitmaps as a 3D array isn't ideal because there's no way to perform a map over all the pixels.

With this representation:

Array DIM3 Word8

Suppose we want to convert the image to greyscale in a single operation. We'd really need a function like:

map1 :: (Array DIM1 a -> Array DIM1 a) -> Array DIM3 a -> Array DIM3 a

However, that doesn't work because we can't guarantee that the worker function always returns an array of the same length as the original. Because of this we can't guarantee that the result is rectangular, and Repa can only deal with rectangular arrays.

If instead we represented Bitmaps as:

Array DIM2 (Word8, Word8, Word8)

Then we could use the original map function and there'd be no problem.

Note that using triples is just as efficient as using a DIM3 array. Repa uses unboxed Data.Vectors to store the manifest array elements, and this library will unpack a vector of triples into three separate vectors holding each of the elements. There are no intermediate tuple constructors or pointers in the underlying representation.

Report from Chris Reade:

That is why I expected this code to work without the explicit seq , but these are needed to avoid the "Performing nested parallel computation sequentially" problem.

writeHeatMapBMP :: String 
                -> Array U DIM2 Double
                -> IO()
writeHeatMapBMP filename arr
  = do maxVal <- foldAllP max 0.0 arr
       minVal <- foldAllP min 0.0 arr
       arrImageOut <- minVal `seq` maxVal `seq`
                      computeP
                      $  R.map rgb8OfDouble
                      $  R.map (rampColorHotToCold minVal maxVal) arr
       writeImageToBMP filename arrImageOut

The implementation of foldAllP should ensure that the result is evaluated before it returns.