bugGNU Octave - Bugs: bug #55486, imread imports PDF(paper) images...


bug #55486: imread imports PDF(paper) images with low 75dpi(screen) resolution

Submitted by:  None
Submitted on:  Wed 16 Jan 2019 04:48:33 AM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  1 - Later Item Group:  Inaccurate Result
Status:  None Assigned to:  None
Originator Name:  Hale Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  4.4.1
Operating System:  Microsoft Windows

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 18 Jan 2019 12:54:58 PM UTC, comment #10:

_>Can Matlab import/read .pdf?

OK! Lets remove all the features that make Octave superior to Matlab_

Come on, please be a little more realistic.
This about a hitch in just one feature that more or less unintendedly seems to work somewhat, but is:

  • unsupported
  • undocumented
  • (judging from completely absent related bug reports) rarely used. Otherwise we would have seen relevant bug reports before.

Yet you do seem to expect that developers will support this apparently rarely used feature even though it was mentioned that fixing & maintaining it requires undue developer time.

A workaround has been suggested. Just try that first.
Octave isn't meant as a substitute for system utilities; fixing those is outside the scope of the project.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 18 Jan 2019 11:56:28 AM UTC, comment #9:

>Can Matlab import/read .pdf?

OK! Lets remove all the features that make Octave superior to Matlab.

(Lets follow the pats of Siemens and Nokia, who were putting a bolt on users, enforcing a strictly limited set of features, and clearing the way for Google and iOS)

Wed 16 Jan 2019 05:10:39 PM UTC, comment #8:

Can Matlab import/read .pdf?

FWIW, imformats ('pdf') in Matlab r2019a pre returns an empty structure.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 16 Jan 2019 03:36:32 PM UTC, comment #7:

The one installed works. But installing it in the system as a 3rd party tool is not an easy task on most Windows systems. It is just better embedded and cross-checked, than standalone with a lot of surprises. So, why don't use its full power from Octave environment natively?

My experience tells that Inkskape particularly DOES NOT work well in windows, depending on installation, build, windows version, windows path, security, and locales configuration. It can seem installed and running, but when you try to do something, you'll see how unstable it is.

I agree, maintenance, and documentation are sources of headache. But why wouldn't you just give a small loophole for tweaking the image-read code? Anyway, 75 dpi itself is an ugly number. it's likke... the year '75.

Wed 16 Jan 2019 03:20:15 PM UTC, comment #6:

And unless you can show me that the behavior you incidentally discovered is documented anywhere, NO, PDF is not supported.

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 03:16:02 PM UTC, comment #5:

If ghostscript (which is installed together with Octave) doesn't work then PDF import through imagemagick won't work either ...
As for Inkscape, no, I don't know that it doesn't work well on Windows since my students have been using it for years.

The "small step" you are talking about is only the visible part of the job. Maintenance is the biggest.

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 03:03:40 PM UTC, comment #4:

you should know that these tools you mention do not work that well on Windows, require a lot of work for installing and tuning and always produce unstable results. And I am often asked to provide the code and the environment installer (one standard environment with one installer for quick deployment), which is Octave. Supporting it with 2-3 outer 3rd party engines is not a solution. People would just tell me to put Octave in a place you can guess, that way...

So something should be done, because vector data is already supported, and just a small step is needed. Maybe some environment variable for setting dpi at least. Or some parameter passed to the reader blindly.

Wed 16 Jan 2019 02:09:17 PM UTC, comment #3:

Yes I agree with comment #2, but this does not change my opinion on this particular feature request: using external tools (ghostscript, inkscape ...) to convert your PDF (or SVG or whatever vector format) to raster formats, you'll have all the options you need (including resolution, cropping, scaling...), and the maintenance burden won't fall on Octave developers.

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 01:59:03 PM UTC, comment #2:

In some situations storing raw high-res multi-page data is much more convenient. Just agree, vector data is more precise and useful for edits and publishing.

There is also another reason: one of common methods of making animated files (GIF, PNG) in Octave is store them first to multipage PDF. Then it can be imread/imwrite to GIF, or PNG by demand.
And there is the underwater rock hidden.

Wed 16 Jan 2019 10:04:58 AM UTC, comment #1:

The fact that imread can import PDF (vector) files is not documented, so not officially supported. I'll change the item group into a "feature request" to add options for importing vector formats.

I am not in favor of adding such capability (and I'll let devs other developpers give their opinion):

  • options like "PixelRegion" will become complicated since the resolution of the rasterizer engine will come into play.
  • it is very easy to do what graphicsmagick does: use ghostscript to first convert the PDF file to raster format and use whatever option you want.

On windows, you'll have to find the ghostcript binary (in the bin folder) and replace "gs" in this example.

Pantxo Diribarne <pantxo>
Project Member
Wed 16 Jan 2019 04:48:33 AM UTC, original submission:

imread() does not have an option for setting vector data interpreter resolution.

One would expect a standard (traditional) resolution to be used depending on the source data type.
I.e. .svg is a web/screen vector data, while .PS, .PDF are formats purely for printable data.
Classic (but outdated) screen resolution is 75dpi.
And for printable data it was always between 300dpi for color, and 400-600 dpi for B/W.

But for some weird and insane reason imread() (_magick_read_ actually) uses 75 dpi for printable PDF sources.

This often makes imported data unusable.

And there is no documentation on _magick_read_ for hacking _imread_() .m code (if it is possible at all)



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-02 rik5 Carbon-CopyRemoved 72865 => -
    2019-03-02 rik5 Priority5 - Normal => 1 - Later

    Back to the top

    Powered by Savane 3.4