Re: Status of receiving color JPEG fax (sent by HP OfficeJet 8600)

On 09/02/2015 08:55 AM, Chris Coleman wrote:
> I've installed HylaFAX+ 5.5.6 from source and am still receiving TIFF 
> images that are stuck in ITULab color space for some reason so just 
> wanted to ask a couple of follow up questions.
>
> Trying to find out why the received TIFF files remain unviewable when 
> they should appear fine with HylaFAX+ 5.5.6

If you're still receiving TIFF with ITULAB Photometric Interpretation 
then you probably don't have LittleCMS.

When compiling HylaFAX, you should see the following messages if you 
expect color fax support:

     Checking for JPEG library support
     ... found. Enabling JPEG library support
     Checking for Little CMS library support
     ... found. Enabling Little CMS support


Run tiffinfo on the received fax image TIFF file.  Among other things 
you should see:

   Bits/Sample: 8
   Compression Scheme: JPEG
   Photometric Interpretation: YCbCr
   YCbCr Subsampling: 2, 2
   Samples/Pixel: 3

If you see "Photometric Interpretation: ITULAB" it means that LittleCMS 
development libraries were not detected during the HylaFAX build.

> 1. I'm seeing in the online HylaFAX+ Sourceforge documentation where 
> it says, just after saying that 5.4.1 supports JPEG/color fax, that 
> it's necessary to still manually patch libtiff.
> http://hylafax.sourceforge.net/howto/install.php#ss2.5

It's only necessary to patch old versions of libtiff.  Current libtiff 
versions do not need to be patched.  I put that information there 
because distributions were not adopting the newer versions of libtiff 
fast-enough (perhaps there was also a long release time involved for 
libtiff v4.0.0, too).

So, that patch isn't a requirement for HylaFAX, per se.  It's just that 
libtiff needed some fixes, too, before it could support color faxes 
properly.

With a modern distribution no patching is required.  For example, on a 
recent Fedora (or RedHat/CentOS with EPEL enabled) just 'yum install 
hylafax+', and all the good bits are acquired.

I will change that website documentation to remove the patch information 
and merely to specify a libtiff version dependency (v4.0.0, I think).  
(Also I need to remove the comment about Class 2.1.)

> As of HylaFAX+ 5.5.6 the latest release version, is this requirement 
> to manually patch rebuild and reinstall libtiff, outdated information, 
> or is it really still necessary to manually patch rebuild and 
> reinstall libtiff today in 2015?

It's outdated as long as you're using v4.0.0 libtiff or newer.

> 2. In reading the bug report and suggested patch on libtiff 4.0 beta 
> from late 2009/2010-2011...
> http://bugzilla.maptools.org/show_bug.cgi?id=2135
>
> I agree with your comment there, that decompressing and immediately 
> recompressing the JPEG image of the color fax page is a pointless loss 
> of quality and an unacceptable workaround just to generate that valid 
> non-null JPEGTables TIFF tag so that the TIFF file would open with all 
> TIFF viewers and convert successfully to PDF with the tiff2pdf command 
> line.
>
> The maintainers comment they have experienced regressions in their 
> tests of your patch to fix the issue in libtiff 4.0.0, so these seem 
> to be somewhat valid reasons for not accepting the patch, which shows 
> status REOPENED.
>
> Has this libtiff patch situation evolved since 2011?

I have commit privileges at libtiff, too.  I think that I committed that 
patch, myself.  I don't know if I call myself a libtiff "maintainer", 
though.  There were regressions that another maintainer resolved a 
couple days after he reported them.  The last comment there from a user 
in 2011 seems to be regarding the version prior to the other 
maintainer's fix.  I think that the bug should be CLOSED and not 
REOPENED, but as I'm not a user of Photoshop I cannot confirm that the 
user's reported problems are, indeed, resolved.

> 3. Has some other technique been implemented for HylaFAX+ to bypass 
> libtiff?

No.  HylaFAX is extremely dependent upon libtiff.  Once upon I time I 
started to investigate removing that libtiff dependency in-favor of 
PDF.  I found that it would involve an incredible amount of work for 
little gain and additional trouble in other places.  So, I have come to 
accept this fact and simply decided to work libtiff code whenever there 
was some kind of trouble.  (Hence, I am involved in occasional libtiff 
development, too.)

> There was mention of using LittleCMS to bypass libtiff and its bug in 
> handling JPEG images inside TIFF ?

Yes, this was necessary to get colors rendered from their original 
colorspace (which would nearly always be something other than ITULAB) 
into ITULAB for sending faxes.  For receiving faxes using LittleCMS 
helps us get the image colorspace into something widely supported (not 
ITULAB) before writing it to the TIFF.  If LittleCMS were not used for 
this then both HylaFAX and libtiff were going to need to recreate same 
the functionality in LittleCMS to accomplish what we needed.  Using 
LittleCMS simplified a lot of things for color fax support.

LittleCMS v1 was supported in HylaFAX v5.4.0, and LittleCMS v2 was 
additionally supported in HylaFAX v5.5.2.

(I really owe a lot of thanks to the LittleCMS developer, Marti Maria, 
who did the lion's share of coding for HylaFAX's use of LittleCMS.  Just 
look at the coding in faxd/itufaxicc.c++. Fortunately, he had an 
academic interest in it.)

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe [email protected] < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail [email protected].*