4
$\begingroup$

The attchd graphics called chromograms represent a set of discrete-state, continuous-time - ie, discrete-event signals, generated with Mathematica 9 on OSX with a Cinema display.

• Top 2 rows are independent signals.

• Bottom two chromograms (red and green) shows the segments where the top 2 rows agree (green) in their temporal coding, and where they differ (red).

So each Rectangle's left and right positions are encoded by 2 timestamps (even-begin and event-end).

X axis is the timeline in seconds, and this graphic shows [200,400] window.

enter image description here

The problem: note there are 3 red rectangles (bottom row) that have no corresponding "holes" in the complementary green signal. This is an error in Mathematica's graphics rendering because closer inspection reveals the holes to be there.

The problem becomes extreme when zooming out to graph a larger time window. In the next figure the same data is shown for the window [0,1800]:

enter image description here

In such a stiff-scale graphic, there are many more instances of the above problem - again, closer inspection shows that the red and green event-signals partition the time-axis so red and green Rectangles should never overlap.

The problem is unrelated to choice of colors - flipping red and green still shows the upper signal to be problematic.

So it seems Rectangles are rendered "too thick" and overlap where they shouldn't.

Are there any Options or methods one could use to control this issue? (Potentially generating a complementary set of interval events and actively rendering them in White may work but haven't tested this and would be a hack in any case).

$\endgroup$
18
  • $\begingroup$ Are you using MMA 9 or an earlier version? $\endgroup$
    – whuber
    Apr 2, 2013 at 19:03
  • $\begingroup$ MMA 9, thanks, will edit that in. $\endgroup$ Apr 2, 2013 at 19:04
  • 1
    $\begingroup$ @bills, seems a MMA9/OSX issue. $\endgroup$ Apr 2, 2013 at 21:17
  • 1
    $\begingroup$ @MinHsuanPeng, that appears to solve it. If you post it as an answer I'll accept it. Interesting that (1) Antialiasing is a graphics primitive, not an Option, and (2) Wolfram tech support isn't aware of this. $\endgroup$ Apr 3, 2013 at 21:12
  • 2
    $\begingroup$ Why are people downvoting this? This is a valid question with a non-obvious (I'd even say: unexpected) solution. Also, @alancalvitti can you test my solution and confirm that we can close this as a duplicate? In my tests it solves the rectangle overlapping problem, but of course it would be much better if you could post some test code so people can try it out without too much hassle. $\endgroup$
    – Szabolcs
    Apr 4, 2013 at 13:54

1 Answer 1

5
$\begingroup$

This is a Mac-only issue and it's present in earlier versions too (not just 9), though with rectangles it manifests itself less commonly in v8 than in v9. To solve the problem, use the option Method -> {"TransparentPolygonMesh" -> True} in Graphics to get rid of this problem. It will also disable antialiasing.

Posts with the same problem, appearing in a different form:

The reason why the mesh appears in those questions is that the polygons are transparent and they overlap slightly (by a pixel or so).


Test code:

g = Graphics[{Opacity[.5], Red, Rectangle[{0, 0}, {.5, 1}], Blue, 
   Rectangle[{.5, 0}, {1, 1}]}]

Magnify[#, 4] & /@ {Rasterize[g, "Image", ImageSize -> 50], 
  Rasterize[Show[g, Method -> {"TransparentPolygonMesh" -> True}], 
   "Image", ImageSize -> 50]}

enter image description here

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.