Thanks, but I have tried this already and didn't work. I should have given more info- I am using Venn::Chart for creating Venn diagrams. This module uses GD to draw the charts.

#!/usr/bin/perl
  use warnings;
  use Carp;
  use strict;
  
  use Venn::Chart;
  
(A) # Create the Venn::Chart constructor
  my $venn_chart = Venn::Chart->new( 500, 500 ) or die("error : $!"); 
+  

(B) my $venn_chart = Venn::Chart->new( 500, 500,1 ) or die("error : $!
+");
[download]

I have tried both ways- A and B. Could it be that Venn::Chart is using default 8-bit image settings while calling GD? Diving into Chart.pm shows up --

sub new {
  my ( $self, $width, $height ) = @_;

  $self = ref($self) || $self;
  my $this = {};
  bless $this, $self;
-----
-----
}
[download]

This tells me that it is taking only width, height as parameters. There are other options also but I am not sure which one to play with as I am not into OOP. Looks like it is time I learn object orientation too.

The problem here is not with GD, but that Venn::Chart is designed to only produce 8-bit images. It would require careful modification to change that.

Personally, I would write my own subroutine to generate a Venn Diagram. Drawing 2 or 3 overlapping circles is not difficult.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Thanks a lot again, I was also coming to the same conclusion after finding that Venn::Chart used only mode A for defining height & width but no option for truecolor. This was a problem I had resigned to without even knowing the reason, but BrowserUK has shown the way and helped me figure this out so easily. I will definitely try churning out my own code :)

In order to view a 500x500 image at 300 dpi, it would have to be displayed or printed on a device capable of 300 pixels per inch -- eg. a printer -- and would show up as 1.67 inches per side.

Or you could scale the image on a wrong-DPI device so that it is of the correct physical dimensions when shown. (Depending on the device's capabilities, you may lose detail.) Nevertheless, your underlying point was that DPI on image files or display devices is largely a tacked-on number most programs don't care one bit about.

Or you could scale the image on a wrong-DPI device so that it is of the correct physical dimensions when shown. (Depending on the device's capabilities, you may lose detail.)

Yes. By embedding the dpi at which an image was recorded or constructed within the image file, it allows for the possibility to scale that image up or down to correct the size when displayed on mismatched devices. But, as you say, detaisl can get lost or become blocky as a result.

The problem is, it encourages the thinking "if I make my images at high dpi, they'll look good whatever device they are shown on", but it doesn't work that way.

If the image is recorded at 300 dpi, and then displayed on a 96 dpi device, it'll either be 3 times too big, or all the fine detail vanishes. And in the bargin, (ignoring compression), you've transmitted 9 times more data than will be used in the final display, for not just no benefit, but negative benefit.

Far better to record images at a lower dpi, that more closely matches the likely display media and offer a click to zoom facility that links to a larger image for those that need one.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?