ImageMagick and GhostScript

mukoya wrote on Sunday, March 20, 2011:

Is ImageMagick and GhostScript still relevant in OEMR 4.0? If yes, what exactly is their role? I have never noticed the difference when they are (not) installed.

Mukoya.

sunsetsystems wrote on Sunday, March 20, 2011:

“convert” and “mogrify” from the ImageMagick package are needed for image processing in the fax/scan module and perhaps elsewhere.  I don’t know offhand about GhostScript.

Rod
www.sunsetsystems.com

tmccormi wrote on Sunday, March 20, 2011:

Imagemagick is used by the Patient “Report” from inside demographics to automatically convert PDF to JPG for inline document viewing.  However it may not actually be working in version 4.  needs testing (or updating) as the feature is very useful.
-Tony

bradymiller wrote on Monday, March 21, 2011:

hey,
The patient ‘report’ conversion feature should still work. Version 4(included in the 3.2 patch also) actually improved this feature by supporting it in windows also:
http://www.openmedsoftware.org/wiki/FAQ#What_is_ImageMagick.3F
-brady

tmccormi wrote on Monday, March 21, 2011:

This is all I ever get….  Imagemagick is installed, but something is not correct, I have not had time to figure out what is missing.

NOTE: Document 'nameofdoc.pdf' cannot be converted to JPEG. Perhaps ImageMagick is not installed?

I don’t (can’t) use the packaged installers as I have to run many instances of OpenEMR that are not in the default installers path model.   Some assumption is being made in the installer that is not necessarily true all the time.

I’m going to poke at this a bit tonight.

-Tony

tmccormi wrote on Monday, March 21, 2011:

PS: these are Ubuntu 10  and CENTOS 5 installations.
-Tony

tmccormi wrote on Monday, March 21, 2011:

Here’s my issue: patient_file/report/print_custom_report.php  doesn’t appear to be handlng the new sites/ directory structure.

# grep convert error.log
convert: unable to open image `/opt/emr_demo/openemr/documents/1/cms1500.pdf': No such file or directory @ blob.c/OpenBlob/2480.
convert: missing an image filename `/opt/emr_demo/openemr/documents/1/cms1500_converted.jpg' @ convert.c/ConvertImageCommand/2838.

tmccormi wrote on Monday, March 21, 2011:

The culprit appears to be: custom_report not print_custom_report
Starting at line 334 …

		    $from_patientid = array_pop($from_all);
		    $from_file = $GLOBALS["fileroot"].'/documents/'.$from_patientid.'/'.$from_filename;
                    $to_file = substr($from_file, 0, strrpos($from_file, '.')) . '_converted.jpg';
                    if (! is_file($to_file)) exec("convert -density 200 \"$from_file\" -append -resize 850 \"$to_file\"");

tmccormi wrote on Monday, March 21, 2011:

This is a patch to fix this problem.

https://github.com/tmccormi/openemr/commit/60c2f04c26f28883503bd9d8bcf9a324a9208b5e

I’ll deliver this to the master -dev branch tonight late if there are no objections.

-Tony

bradymiller wrote on Monday, March 21, 2011:

Tony,

This won’t be very helpful. You need to remember to send the file via /controller.php?document&retrieve&patient_id=&document_id= (like the code your removing does). Otherwise, only installations that are insecure will be able to view these (and you’ll be removing a bug I fixed awhile back regarding this issue).

-brady

tmccormi wrote on Monday, March 21, 2011:

I just did exactly what is already being done in printed_custom_report.php.   I don’t have a clue how to use controller on document that is not in the database.  These documents are converted on the fly they don’t have document id’s.  If this is wrong then both should be considered bugs, in which case it should be a common function call in the library for all cases.

Would you mind explain how converting  a pdf to jpg and viewing it using normal html img tag is a security issue?  That’s one thing that has always baffled me.

If  $from_file = $d->get_url_filepath(); is an invalid or insecure way to get a document path then the option should be removed from the library.

-Tony

bradymiller wrote on Monday, March 21, 2011:

Tony,
A secure OpenEMR installation will not allow direct viewing of anything in the documents directory (this is covered in one of the installation steps). Just consider the ramifications if you don’t have apache protect these directories (ie. anybody can fish for patient documents in these directories without even being logged into OpenEMR). You went through all this with the patient photos on the patient summary page. Looking through your code, it looks like the correct call is there, but has been removed:

 echo "<img src='" . $GLOBALS['webroot'] . "/controller.php?document&retrieve&patient_id=&document_id=" . $document_id . "&as_file=false&original_file=false'><br><br>"; 

Change to:

 echo "<img src='" . $GLOBALS['webroot'] . "/sites/" . $_SESSION['site_id'] . "/controller.php?document&retrieve&patient_id=&document_id=" . $document_id . "&as_file=false&original_file=false'><br><br>"; 

May suffice here. Note there is a parameter here call original_file which is set to false. Also note I added that feature to fix the bug you’re about to revert to :slight_smile: Also, as an aside ifs the printed_custom_report.php even be used anywhere (I haven’t grepped for it or anything, just wondering).

-brady

bradymiller wrote on Monday, March 21, 2011:

Tony,

Forget my advice above(that line will not likely work). The only line to fix I think is where you convert the image:

$from_file = $GLOBALS["fileroot"].'/documents/'.$from_patientid.'/'.$from_filename;

TO:

$from_file = $GLOBALS['fileroot'] . "/sites/" . $_SESSION['site_id'] . '/documents/'.$from_patientid.'/'.$from_filename;

(note I’m doing this off the top of my head; can’t get to a development environment right now)

-brady

bradymiller wrote on Monday, March 21, 2011:

Tony,
Also note an additional bug your including in this code (that has previously been fixed) is reliance on the path $d->get_url_filepath(); . Note this will break if you move the installation somewhere that the directory structure changes (such as rom drive c to drive d etc.); note this is why the code you removed only collects the filename and patient id from the url instead of the full path. I think that my above modification in the original code should get the correct functionality (or at least lead you down the right direction).
-brady

tmccormi wrote on Monday, March 21, 2011:

Thanks Brady, as you can see I’m not the only one confused by this part of the document process :-)    I’ll post an updated commit later today . based your suggestion.

$from_file
= $GLOBALS["fileroot"].'/documents/'.$from_patientid.'/'.$from_filename;

TO:

$from_file = $GLOBALS['fileroot'] . "/sites/" . $_SESSION['site_id'] .
'/documents/'.$from_patientid.'/'.$from_filename;

-Tony

bradymiller wrote on Monday, March 21, 2011:

Tony,

Sounds good, but test it first (I don’t have access to a development environment right now). After you commit it to master, I’ll then cherry-pick it to the rel-400 branch).

Also, this code brings to light a critical bug in Ken’s rename document code. These converted documents are kept around, so changing document names can obviously screw things up. simplest option is to remove previously converted before doing the conversion. This will dramatically slow down report generation since can never use previously converted files. Other more complicated option is to work the fix into ken’s code; remove any converted files when change name that either have initial or new name.

doggmd wrote on Saturday, February 09, 2013:

The error “NOTE: Document’xxxxxxxxxxxx_1_01172013.pdf’ cannot be converted to JPEG. Perhaps ImageMagick is not installed?”  seems to still be present.

This is with Windows 7x86,Firefox, imagemagick,OpenEMR 4.1.1 patch , all with latest versions,
The pdf file displays fine in the Documents section.

Is a fix available or in the works?

ajperezcrespo wrote on Sunday, February 10, 2013:

I have the same issue.  But my install is Ubuntu 12.04 Server OpenEMR 4.1.1(9).
I also have the problem in the Scanned Notes form on Ubuntu 12.04 OpenEMR 4.1.0(13).

No problems with PDFs but doesnt like JPGs.

Oddly enough you can upload a JPG but you need to rename it with a PDF extension.  Then it works (annoyingly) just fine.

Alfonso

bradymiller wrote on Wednesday, February 13, 2013:

Hi,

Regarding windows, there is a faq item on this here:
http://open-emr.org/wiki/index.php/FAQ#What_is_ImageMagick.3F

Regarding ubuntu, was this working for you on the previous OpenEMR version(s)?

-brady
OpenEMR

ajperezcrespo wrote on Friday, February 15, 2013:

Yup it sure was.

And as far as the scanned documents form….
It uploads properly but when one goes to view it  you get a “client denied by server configuration” .  I checked the permissions and they are good to go.
Any thing else to look at?

BTW: I was able to reproduce this in a test environment with stock install.  Plain simple ubuntu server install, deb and patched.  Just copied over the db and sites folders…

Thanks