Tiff2pdf 16 bit support

gutiersa wrote on Friday, February 17, 2012:

freebsd
tiff-4
php5
apache22
openemr-4.1.0_7

When I use the fax/scan interface to upload files to patient charts, after checking the radio button, choosing patient and category, when I hit enter, I am getting the following error:

tiff2pdf: No support for /path to file_path/faxcache/scan/xxx_lab_xxxxxxxx/temp.tif with 16 bits per sample.

is 16 bits what openemr uses? how can I get 16 bit support? Or is using 32 bit possible?

Please help. I am short staffed and I think the fax/scan interface is a more efficient way of uploading documents.

thanks so much

sandra

deschel wrote on Thursday, June 26, 2014:

I am having the same problem. What do I need to do to fix this?

cmswest wrote on Thursday, June 26, 2014:

hi david, must be happening here

it this a one time problem with just this file?

from some quick research, 16 bits per sample is a common compression that should be handled

which version of ghostscript and libtiff-tools are you running?

ghostscript -v
dpkg -l | grep ‘^ii’ | grep libtiff

deschel wrote on Friday, June 27, 2014:

Ghostscript 9.10
Libtiff 4.0.3

I am running it on my test environment which is Mac OS X. Ghostscript and libtiff were installed with macports.

When I do tiff2pdf on the command line, it gives the same error.

It occurs with all files that I have attempted to use.

Thanks

deschel wrote on Friday, June 27, 2014:

I take my last statement back.

If I dispatch a tiff file that came from the fax with 1 Bit/sample then dispatch works.

It seems that the problem arises when I select a pdf to dispatch.

Apparently, OpenEMR converts the pdf to tiff whereby the tiff has 16 bits/sample (which creates a very large file size in the fax cache folder), then at the end when everything is done, it converts it to a pdf.

deschel wrote on Friday, June 27, 2014:

I went to my Linux machine, running Ubuntu 14.04 LTS and latest version of libtiff (4.0.3).

And, the same thing happened!

I eliminated variables by using tiff2pdf from the command line (not from openEMR) and it gives the same error:

No support for xxx.tif with 16 bits per sample.

So, to me, it looks like OpenEMR is broken for anyone who uses scan/fax to add pdf documents to OpenEMR.

Has anyone been able to successfully do this? Because, it looks to me like it is simply not possible with the current version of OpenEMR and the latest version of libtiff.

deschel wrote on Friday, June 27, 2014:

Easy to fix.

Instead of using tiff2pdf, I changed it to:

convert xxx.tif -compress JPEG xxx.pdf

Now, no error. I would have thought of this as a core feature used by most physician offices implementing the EMR. So, I am really surprised it wasn’t fixed.

Am I missing something?

cverk wrote on Friday, June 27, 2014:

I just scan to PDF in my scanner software which is paperport and then upload them through documents without any problems. I have more of a problem getting them back out under reports to send elsewhere. When I use the download PDF button, I get this error below. When I use the generate report button it doesn’t give you all the pages of a multipage PDF. So I have had to save PDF’s one at a time out of the patient file and then stack them under paperport to fax or burn to CD which is kind of a pain.

File : C:\xampp\htdocs\openemr\library\html2pdf\parsingHTML.class.php
Line : 99

HTML code invalid, the tags are not closed in an orderly fashion.
Status :

Array
(
[0] => div
[1] => div
[2] => div
[3] => table
[4] => tr
[5] => td
[6] => table
)

HTML : …lass=‘text’ valign=‘top’>

<td val…

cmswest wrote on Friday, June 27, 2014:

i don’t think so

doesn’t the above convert command just give you an alternate way to handle the tifs?

what’s your fix for pdfs?

deschel wrote on Saturday, June 28, 2014:

That is my fix for pdfs.

The way that fax dispatch works for pdfs is as follows:
(1) Convert pdf to tiff (using command line application convert).
(2) Split the multipage tiff to single page tiffs (using commandline application tiffsplit).
(3) Processing for Display / User Selection --> creating a new tiff file.
(4) Convert tiff file to a pdf (using tiff2pdf).
(5) Copy pdf to documents folder to go to patient’s chart.

Now, if the scanner or fax server creates a tiff file, then you start at step 2.

Most scanners do not create tiffs with 16 bits per sample.
Fax machines, which are b/w, only creates tiffs with 1 bit per sample.

Therefore, tiff2pdf works with these files.

The problem is that convert (in step one) creates a tiff file with 16 bits per sample.

The latest version of tiff2pdf cannot handle files with 16 bits per sample (due to a documented bug that was fixed at sometime in the past, but apparently came back in later versions.) Hence, the error.

You can describe the error basically as an incompatibility between “convert” and “tiff2pdf”.

This is a conclusion based upon my research and testing. If I am wrong, please correct me.

cmswest wrote on Saturday, June 28, 2014:

nice work and thanks for the explanation

guess everyone is outputting tiffs from their scanners, except for users like Cverk who upload documents by going into the patient’s chart instead of using the built in fax/scan module under miscellaneous on the left nav

so the line i referenced above should now be:

  $tmp0 = exec("convert '$faxcache/temp.tif' -compress JPEG '$target'", $tmp1, $tmp2);

but maybe you need to specify the size like the tiff2pdf command did with the -p letter?