Image issue

[swalker]

Every image on my rendered pdf has a blur to it, is there some way I
should be saving my images out? Or some kind of compression/ratio
issue that I am not aware of. Even if I put the images at 300dpi they
still get a pixelated border around the edges. The only way I can
solve this is to save an image twice as big as it is supposed to be
and scale it down by .5

Anyone out there have information about the image treatment here?
Thanks

[Arco]

I've been saving my images out as jpg with no special treatment.
Every one has come out perfect. Maybe you could try jpg, if you're
using another format...

[James Healy]

swalker wrote:
> Every image on my rendered pdf has a blur to it, is there some way I
> should be saving my images out? Or some kind of compression/ratio
> issue that I am not aware of. Even if I put the images at 300dpi they
> still get a pixelated border around the edges. The only way I can
> solve this is to save an image twice as big as it is supposed to be
> and scale it down by .5

Can you provide a sample image and PDF that exhibits the issue?

-- James Healy <jimmy-at-deefa-dot-com> Thu, 17 Sep 2009 09:24:28 +1000

[thoughtafter]

I am also having this issue and I wonder if you found a solution. I
will try to get some examples but this project works with user data
that I cannot disclose but I will try to mock up some data.

I have an image, and embed it into a pdf using prawn. When viewing
both at 100% the image in prawn is clearly scaled up. To get them at
about the same size I used:

pdf.image(@image, :scale=>0.75)

That makes the images the same size but the image within the pdf looks
as though it has been scaled (up and down?) and appears blurry. I've
tried this with both job and png (with and without fast-png) and
always seem to get the same result. I've considered increasing the
dpi of the document but that seems like it could be a hassle.

Any advice would be much appreciated.

Jesse

[James Healy]

thoughtafter wrote:
> Any advice would be much appreciated.

Can you provide a sample image and PDF that exhibits the issue?

cheers

-- James Healy <ji...@deefa.com> Tue, 27 Oct 2009 13:27:22 +1100

[jesse]

Here you are.

The test image was generated with ploticus:

ploticus -prefab pie data=data23 delim=tab values=2 labels=1
colorfld=3 title="Colors from data field" legend=yes -png -o
testimage.png

The pdf was created with:

p = Prawn::Document.new do |pdf|
pdf.image(open('testimage.png'))
pdf.image(open('testimage.png'), :scale=>0.75)
end
p.render_file('test.pdf')

Thanks,
Jesse

[Dott. Scolavino Alessandro]

I guess you can try to change image size using imagemagick or something
similar

jesse ha scritto:

> ------------------------------------------------------------------------
>


--
- --
Ai sensi del DL 196/2003 si precisa che le informazioni contenute in questo
messaggio sono riservate ed a uso esclusivo del destinatario. Qualora il
messaggio in parola Le fosse pervenuto per errore, la Preghiamo di
eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente
comunicazione. Grazie.

Cordiali saluti

- ---- Dott. Alessandro Scolavino ----

[James Healy]

Thanks for the sample code.

jesse wrote:
> ploticus -prefab pie data=data23 delim=tab values=2 labels=1
> colorfld=3 title="Colors from data field" legend=yes -png -o
> testimage.png

This command requires a program and data file, neither of which I have.
Please generate a sample image and PDF and email it to me.

regards

-- James Healy <ji...@deefa.com> Wed, 28 Oct 2009 01:06:16 +1100

[James Healy]

James Healy wrote:
>
> Thanks for the sample code.
>
> jesse wrote:
> > ploticus -prefab pie data=data23 delim=tab values=2 labels=1
> > colorfld=3 title="Colors from data field" legend=yes -png -o
> > testimage.png
>
> This command requires a program and data file, neither of which I have.
> Please generate a sample image and PDF and email it to me.

My bad. I missed the attachments. Sorry. I'll have a look at what the
cause might be tomorrow.

-- James Healy <ji...@deefa.com> Wed, 28 Oct 2009 01:09:01 +1100

[James Healy]

Honestly, I'm not quite sure what's going on here.

I can reproduce the issue - the embedded image looks slightly larger
(and lower quality) than the raw image. Interestingly, if I build a PDF
using the ruby/cairo bindings, a similar effect occurs.

Greg, Brad, can you shed any light here?

-- James Healy <ji...@deefa.com> Wed, 28 Oct 2009 12:28:28 +1100

[Gregory Brown]

On Tue, Oct 27, 2009 at 9:28 PM, James Healy <ji...@deefa.com> wrote:
>
> Honestly, I'm not quite sure what's going on here.
>
> I can reproduce the issue - the embedded image looks slightly larger
> (and lower quality) than the raw image. Interestingly, if I build a PDF
> using the ruby/cairo bindings, a similar effect occurs.
>
> Greg, Brad, can you shed any light here?

Sorry, I'm really out of my element when it comes to image stuff.
Hopefully Brad or someone else can give us a reason why this is
happening.
James, is this happening for this image in particular, a certain type
of PNG, all PNG, all images?

-greg

[Brad Ediger]

It appears to be somewhat specific to this PNG or this type of PNG (maybe something with the creator application?). I get the same result when using ImageMagick:

  convert testimage.png test-imagemagick.pdf

I'm also out of my element in this image code, but I'll be doing some research when time opens up.

Brad

[Brad Ediger]

On Mon, Oct 26, 2009 at 11:18 PM, jesse <though...@gmail.com> wrote:
> Here you are.
>
> The test image was generated with ploticus:
>
> ploticus -prefab pie  data=data23  delim=tab  values=2  labels=1
> colorfld=3        title="Colors from data field"  legend=yes -png -o
> testimage.png
>

Hi Jesse,

That image is being generated at 72 dpi, which is a fairly low
resolution even for screen output. (The default resolution on Windows
is 96 dpi). Some quick research indicates that most PDF viewers treat
"100% zoom" as meaning a 1:1 ratio of document inches to screen
inches, so that might be the cause of the issues here. Reinforcing
this hypothesis, every method we've tried of converting that image to
PDF results in the same problem.

We might have better luck if you can at least double the resolution of
that source image, while keeping it the same size. I can't seem to
figure out if Ploticus can do that on its PNG backend, so you may have
to generate a large image and scale it back in PDF generation or using
an external program.

Brad

[jesse]

Brad,

It does make sense that it would be a DPI issue as 96/72=0.75 which
seems to be the factor the image is off by. It also makes sense because
I experienced this with JPG as well as PNG. However, it my
investigations it seems that Prawn defaults to 72 DPI.

From prawn-core-0.5.1/lib/prawn/document/page_geometry.rb:

"LETTER" => [612.00, 792.00]

8.5 * 72 = 612
11 * 72 = 792

So if that's the case shouldn't Prawn want images that are 7 2DPI? In
the short term I will change the DPI information and see if that fixes
the problem.

Thanks,
Jesse

[Gregory Brown]

On Wed, Oct 28, 2009 at 2:59 PM, jesse <though...@gmail.com> wrote:
>
> Brad,
>
> It does make sense that it would be a DPI issue as 96/72=0.75 which
> seems to be the factor the image is off by.  It also makes sense because
> I experienced this with JPG as well as PNG.  However, it my
> investigations it seems that Prawn defaults to 72 DPI.

Prawn does all measurement points in PDF points which are 1/72 in.
This does not indicate a preference for what resolution your images
should be rendered in, but rather a sensible standard unit as it's
what PDF uses naturally.

I would be interested in some autodetection code for properly scaling
images at different resolutions, but I'd need to hear from folks with
domain experience as to whether that'd be desireable / possible, etc.

-greg

[Brad Ediger]

On Wed, Oct 28, 2009 at 2:05 PM, Gregory Brown
<gregory...@gmail.com> wrote:
>
> On Wed, Oct 28, 2009 at 2:59 PM, jesse <though...@gmail.com> wrote:
>>
>> Brad,
>>
>> It does make sense that it would be a DPI issue as 96/72=0.75 which
>> seems to be the factor the image is off by.  It also makes sense because
>> I experienced this with JPG as well as PNG.  However, it my
>> investigations it seems that Prawn defaults to 72 DPI.
>
> Prawn does all measurement points in PDF points which are 1/72 in.
> This does not indicate a preference for what resolution your images
> should be rendered in, but rather a sensible standard unit as it's
> what PDF uses naturally.

PDF has the concept of "user space" and "device space", and uses a
transformation matrix to map between them. User space, by default,
uses units of 1/72 of an inch, hence all of the references to 72 in
the Prawn source. This is actually pretty important to keep in mind --
those units are completely arbitrary and do not correspond to
"points", "dots", "pixels", or anything else.

Brad

[Wojciech Piekutowski]

2009/10/28 Gregory Brown <gregory...@gmail.com>:

This is a bit complicated, but I'll do my best to explain... I assume
you know what are: 'screen DPI' (DPI), 'PDF point' (PDF pt), 'pixel'
(px).

In Acrobat Reader for Linux you can set custom screen DPI. After
setting it to 72 the image in question looks properly. When DPI == 72
and zoom == 100% (or more precisely DPI*zoom == 72): 1 screen px === 1
PDF pt. In this case a simple #image(filename) works, in any other
case your PDF reader needs to scale the image.

I think it's not really possible to achieve super quality unless you
can assume some specific DPI and zoom on the user side. For example if
you want to have image that will occupy 100x100 PDF pt:
- at 72DPI, 100% - you need 100x100px image. #image(filename) will do
the same as #image(filename, :width => 100)

# this example demonstrates that :width is useless at 72 DPI
pdf = Prawn::Document.new
pdf.image(testimage.png', :width =>422) # in PDF pt - same value as
the real image width in px
pdf.image('testimage.png')
pdf.render_file('test.pdf')
# both look sharp and nice at 72DPI

- at 216DPI, 100% - you need an image with 100[PDF pt] * 216[px/in] /
72[PDF pt/in] = 300[px] - 300x300px. #image(filename, :width => 100) -
:width is important - you need to tell your PDF reader to scale the
image when DPI != 216. On a typical screen it won't look perfect, but
a printer will be able to use that extra DPIs to produce a better
looking printout. This means you need to carefully calculate the real
image size to get what you want.

If you're pedantic - it's good to adjust [PDF pt] size (100 in the
example above) so that the [px] result is an integer. For example a
typical laser printer is capable of 600DPI. You need to use
100*600/72=833.333px image. Oops, not possible, but if you use 102
[PDF pt] you'll get a nice result - 850px.

It's usually reasonable to use bigger DPI, say 150 or 300, for raster
graphics to enable nice printouts and better experience for people
with high-DPI screens.

I believe that text and fine graphics are not very good candidates for
the raster format. Only photo-like content should be embedded in this
way. swalker, you'd better use existing Prawn facilities to draw this
pie-chart and legend. It will look great at any DPI, any zoom, any
display, any printer.

Greetings,
Wojtek

[Brad Ediger]

On Wed, Oct 28, 2009 at 4:56 PM, Wojciech Piekutowski
<w.piek...@gmail.com> wrote:
>
> I believe that text and fine graphics are not very good candidates for
> the raster format. Only photo-like content should be embedded in this
> way. swalker, you'd better use existing Prawn facilities to draw this
> pie-chart and legend. It will look great at any DPI, any zoom, any
> display, any printer.

I still think you could get good results with higher-res raster
graphics. But if you want to go the vector route, Daniel Nelson just
published PrawnVectorImport [1] a few days ago. It can import vector
graphics from PDF documents and some Illustrator files into Prawn.
That may be able to be bent to your needs, though I realize it's not
as simple as pulling the output of a graphing library.

[1] http://github.com/Bluejade/PrawnVectorImport

[jesse]

Ok, a couple of follow-up questions:

1. Is there any way to insert an image such that it does not get
scaled, in other words an image that would be small on a high DPI screen
but larger on a lower DPI screen?

2. Does adjusting the scale/width/height alter the DPI of the image or
does Prawn scale the image? Does Prawn always put a pixel for pixel
copy in the PDF or does it alter the image in any way?

Also, while it's nice to have an option to use vector graphics (SVG
would be a welcome addition) I've gotten complaints about photo images
being blurry. So I'm trying to develop some guidelines to avoid that.
I'm planning on testing images with various DPI settings and Prawn with
various scale settings and see what looks decent.

Thanks,
Jesse

[Brad Ediger]

On Wed, Oct 28, 2009 at 8:58 PM, jesse <though...@gmail.com> wrote:
>
> Ok, a couple of follow-up questions:
>
> 1.  Is there any way to insert an image such that it does not get
> scaled, in other words an image that would be small on a high DPI screen
> but larger on a lower DPI screen?

I think the discussions on screen resolution may have been throwing
you off here. The size of an image relative to the document is not in
any way dependent on the output device. An image half the width of the
page will always be half the width of the page regardless of your zoom
level, screen resolution, or anything -- even when printed.

> 2.  Does adjusting the scale/width/height alter the DPI of the image or
> does Prawn scale the image?  Does Prawn always put a pixel for pixel
> copy in the PDF or does it alter the image in any way?

Prawn does put a "sample"-for-pixel copy into the PDF ("sample" being
the PDF imaging term for one pixel in an embedded image), but bear in
mind that those have absolutely no correspondence to pixels on the
output device (screen, etc).

To more directly answer your question: Yes, every pixel of the source
image is embedded in the PDF. Prawn does no resampling of any kind.
All of the knobs you can twist in Prawn control the transformation
matrix -- the way that those pixels map to the output device. And it
is the reader that will be doing that rendering and any resampling
necessary -- if you have an extremely high resolution image that is
scaled way down in the PDF (or, somewhat equivalently, if you're
zoomed far out), the reader will have to downsample in order to
display it. On the contrary, if you've got a 72dpi source image at
100% that you're trying to print on a 600dpi printer, that software is
going to have to come up with a lot of pixels that just aren't there.

So the long and short of it is that if you just crank up the DPI in
your source image and play around with the scale parameter, I think
you'll see better output. Let us know if you have success.

Brad

[jesse]

Just a few follow-ups:

1. Changing the DPI of the image has no effect on the image in prawn.
And that makes sense since Prawn does not seem to utilize DPI
information anywhere but it probably should.

2. On my development machine I upgraded to Ubuntu 9.10 and the images
look terrible. I suspect this is an evince bug but I thought it would be
worth mentioning. It looks like the image scaling is using some sort of
nearest neighbor algorithm. I tested in acrobat reader on virtualized
windows system and it looked as good as it has looked (ie, barely
acceptable to my client).

3. I think I'm going to abandon this approach. I think it is useful for
people to know that, for now, they should use high resolution images and
the scale parameter for photographic images but for the graphs and
charts we are generating I think SVG is the path forward. Is anyone
thinking on implementing SVG for Prawn? Anyone have any idea what it
would take to implement as I may be able to get my client to fund my
time to do so.

Thanks,
Jesse


Brad Ediger wrote:

[Gregory Brown]

2009/11/5 jesse <though...@gmail.com>:

> 2. On my development machine I upgraded to Ubuntu 9.10 and the images
> look terrible. I suspect this is an evince bug but I thought it would be
> worth mentioning. It looks like the image scaling is using some sort of
> nearest neighbor algorithm. I tested in acrobat reader on virtualized
> windows system and it looked as good as it has looked (ie, barely
> acceptable to my client).

Only Mac OS X Preview and the latest version of Acrobat Reader are
supported for Prawn atm.
(in the sense that we test in them before every major release). We
code to spec, so rendering issues *should* be with the viewer and not
Prawn.

Of course, we'll try to fix any bugs that are found.

> 3. I think I'm going to abandon this approach. I think it is useful for
> people to know that, for now, they should use high resolution images and
> the scale parameter for photographic images but for the graphs and
> charts we are generating I think SVG is the path forward. Is anyone
> thinking on implementing SVG for Prawn? Anyone have any idea what it
> would take to implement as I may be able to get my client to fund my
> time to do so.

You might want to hunt down @seancribbs as he was mentioning a
scruffy->prawn transformation on Twitter, though i'm not sure he
released any code.
Basically, you need to map SVG to our drawing primatives to get vector
graphics. I don't mind adding new primitives where needed, and would
love to see SVG support in Prawn.

Since we're seeing contributions for a lot of things I said I'd never
expect to see implemented, who knows, maybe this will get done sooner
rather than later :)

-greg

[Daniel Nelson]

> 3. I think I'm going to abandon this approach. I think it is useful for
> people to know that, for now, they should use high resolution images and
> the scale parameter for photographic images but for the graphs and
> charts we are generating I think SVG is the path forward. Is anyone
> thinking on implementing SVG for Prawn? Anyone have any idea what it
> would take to implement as I may be able to get my client to fund my
> time to do so.

I would think that an application that could export SVG could also
export PDF. Check whether your graphing program can export vector
graphic PDFs. If so, it is super easy to use the pdf-reader gem to
import data from an existing PDF into a Prawn project (check out
PrawnVectorImport to see how I did it:
http://github.com/Bluejade/PrawnVectorImport).

-Daniel

[Wojciech Piekutowski]

2009/11/9 Daniel Nelson <dnel...@gmail.com>:

>
>> 3. I think I'm going to abandon this approach. I think it is useful for
>> people to know that, for now, they should use high resolution images and
>> the scale parameter for photographic images but for the graphs and
>> charts we are generating I think SVG is the path forward. Is anyone
>> thinking on implementing SVG for Prawn? Anyone have any idea what it
>> would take to implement as I may be able to get my client to fund my
>> time to do so.
>
> I would think that an application that could export SVG could also
> export PDF. Check whether your graphing program can export vector
> graphic PDFs.

You can also convert SVG to PDF like this:
inkscape -z --file=logo.svg --export-pdf=logo.pdf

Greetings,
Wojtek

[Rodney Carvalho]

I'm having the same issue as well.

On Thursday, April 18, 2013 2:24:06 PM UTC-4, alain pilon wrote:

Sorry for pulling this one out of the graveyard but I am having the same issue. Anyone found a solution in the last 4 years?

[Gregory Brown]

The solution is to make sure your image has a sufficiently high DPI and then downscale as needed to fit on your document. This isn't a Prawn bug as far as we know.