I'm having some trouble with TIF/TIFF's, and am wondering if anyone has had similar issues and addressed them, or if others are having no issue at all with such files and hopefully how your setup differs from mine.

My basic setup is:
Ubuntu 12.04 (64-bit)
Zenphoto 1.4.3.2
Default theme
PHP version: 5.3.10-1ubuntu3.2
Graphics support: PHP Imagick library 3.1.0RC1
ImageMagick 6.6.9-7 2012-08-17 Q16
'convert -list configure' shows TIFF under delegates
'identify -list format' shows TIFF as rw+, with libtiff version 3.9.5
class-WEBdocs is enabled but TIFF disabled (attempting various options, including disabling it entirely, doesn't fix the issue described below, just alters how the browser displays the issue)
Several other plugins are enabled, none of them 3rd party uploads, and no others appear to have anything to do with TIFF's; otherwise everything is "stock" Zenphoto.

TIF/TIFF files and thumbnails appear to work with other programs, such as 'digikam' and 'image viewer'.

However, when I place a TIF/TIFF in a Zenphoto directory and attempt to view, issues begin. First, Zenphoto does not recognize any file with only a TIF extension (perhaps this is related to imagick?). Renaming to a TIFF extension leads to Zenphoto recognizing the file and even pulling metadata from it, a workaround I could certainly live with - but that brings me to the second issue, which is not generating a usable/used thumbnail.

By that I mean in album view I see only the filename or caption text as a link, instead of a thumbnail -- there's not even a placeholder box, just text, which is very jumbled if it's trying to show a long caption. But upon looking in the relevant cache folder, there is in fact a generated file -- <filename>_100_w100_h100_thumb.tiff. Sometimes that file can be opened (directly from the cache folder) and appears to be a perfectly good thumb sized image of the original, but sometimes that file appears to be black or blank ('image viewer' properties show it to be a 100x100 image, but otherwise the image appears to view as just a black box). In either case, it is not shown as a thumb in Zenphoto, just the text link. Clicking on the text opens the image viewing page, however with class-WEBdocs/TIFF disabled there is no image, just the filename or caption as a link to the full image. Clicking on the full image link will load the full image.

I've used TIFF's from a few different sources, although not in much volume. All of them have been around 12MB or less, so not huge files, but I'd really rather not have to add another step by converting the ones I have -- especially when this seems so close to working. The ones with black box thumbnails only seem to all have been generated by Silverfast (scanning software), and I might blame that except those same images work fine in other programs. The generated thumbs from other TIFF's I can view in something like 'image viewer', but still aren't being shown in Zenphoto for some reason.

So that's a long way of saying, does anyone have an idea why this isn't working or what I might try to address it?

Thanks!

I just tried on my live test site as well with Imagick and tiffs also don'T work. I get an php error:

Backtrace: USER NOTICE: Method Not Allowed in ******/zenphoto/zp-core/functions-image.php on line 33
trigger_error called
from imageError (functions-image.php [33])
from i.php [239]

What I found out is that at least my imagick wants the suffix ".tiff" and not ".tif". For unknown reasons the first loading does not create the image but on reloading the page. LZW compression did not matter.

I will add the keyword "imagick" to this topic so our colleague who helped out with this lib will possibly spot it.

Thanks. At least now I know I'm not crazy!

The Imagick lib will use any formats that are available to it from ImageMagick. If `.tif` is not working, then there must not be explicit support for it. (It will be listed separately from `.tiff` in the formats list.)

The problem with the TIFF format is that there are so many variations of it that it becomes difficult to tell whether a given image will work or not. If these images are all coming from Silverfast, then I would guess that these images are somehow invalid to ImageMagick.

For one of the images that fails, would you post the output of this command:

`identify -verbose image.tiff`

You might also try to `convert` one of these images directly through CLI to test if ImageMagick can process the image and what it outputs.

Attempting 'identify' on either the TIF or TIFF extension provides what appears to be identical output, although I haven't done a character by character comparison.

Identify verbose of a Silverfast file, with basic redactions:
`


Image: (redacted).tiff

Format: TIFF (Tagged Image File Format)

Class: DirectClass

Geometry: 2442x1650+0+0

Units: PixelsPerInch

Type: TrueColor

Base type: TrueColor

Endianess: MSB

Colorspace: RGB

Depth: 8-bit

Channel depth:

red: 8-bit

green: 8-bit

blue: 8-bit

Channel statistics:

Red:

min: 0 (0)

max: 255 (1)

mean: 52.479 (0.2058)

standard deviation: 61.3163 (0.240456)

kurtosis: 1.20736

skewness: 1.38792

Green:

min: 0 (0)

max: 254 (0.996078)

mean: 48.1431 (0.188797)

standard deviation: 58.7233 (0.230287)

kurtosis: 2.59822

skewness: 1.80257

Blue:

min: 0 (0)

max: 255 (1)

mean: 44.2458 (0.173513)

standard deviation: 55.0559 (0.215906)

kurtosis: 4.35784

skewness: 2.26676

Image statistics:

Overall:

min: 0 (0)

max: 255 (1)

mean: 48.2893 (0.18937)

standard deviation: 58.4217 (0.229105)

kurtosis: 2.5332

skewness: 1.79247

Rendering intent: Undefined

Interlace: None

Background color: white

Border color: rgb(223,223,223)

Matte color: grey74

Transparent color: black

Compose: Over

Page geometry: 2442x1650-9223372036854775808-9223372036854775808

Origin geometry: -9223372036854775808-9223372036854775808

Dispose: Undefined

Iterations: 0

Compression: None

Orientation: TopLeft

Properties:

comment: (comment redacted)

date:create: 2012-09-06T11:04:45-04:00

date:modify: 2012-02-29T23:25:02-05:00

rdf:Alt:

rdf:Bag:

signature: 4389f72bbe70cb5f973f8c68141ee15c43dcf015292e44be4c0f810ad968d07e

tiff:endian: msb

tiff:photometric: RGB

tiff:rows-per-strip: 1

tiffoftware: SilverFast 8.0.1 r5 (Feb 1 2012) Canon Master 01.02

Profiles:

Profile-icc: 3144 bytes

IEC 61966-2.1 Default RGB colour space - sRGB

Profile-iptc: 316 bytes

Originating Program[2,65]: digiKam

Program Version[2,70]: 2.5.0

Caption[2,120]: (caption redacted)

Keyword[2,25]: (redacted)

Keyword[2,25]: (redacted)

Keyword[2,25]: (redacted)

Keyword[2,25]: (redacted)

Profile-xmp: 5047 bytes

Artifacts:

verbose: true

Tainted: False

Filesize: 12.1MBB

Number pixels: 4.029MB

Pixels per second: 134.3MB

User time: 0.010u

Elapsed time: 0:01.030

Version: ImageMagick 6.6.9-7 2012-08-17 Q16 http://www.imagemagick.org

identify: (redcted).tiff: unknown field with tag 11 (0xb) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/706.
`
Identify verbose of a tif/tiff generated I believe after editing a RAW Canon camera file, evidently using Photoshop at some point:

`


Image: (redacted).tiff

Format: TIFF (Tagged Image File Format)

Class: DirectClass

Geometry: 1392x994+0+0

Resolution: 72x72

Print size: 19.3333x13.8056

Units: PixelsPerInch

Type: TrueColor

Base type: TrueColor

Endianess: MSB

Colorspace: RGB

Depth: 8-bit

Channel depth:

red: 8-bit

green: 8-bit

blue: 8-bit

Channel statistics:

Red:

min: 16 (0.0627451)

max: 252 (0.988235)

mean: 113.341 (0.444473)

standard deviation: 68.7284 (0.269523)

kurtosis: -1.33861

skewness: 0.492273

Green:

min: 18 (0.0705882)

max: 225 (0.882353)

mean: 98.4746 (0.386175)

standard deviation: 56.4913 (0.221534)

kurtosis: -1.02831

skewness: 0.707186

Blue:

min: 0 (0)

max: 168 (0.658824)

mean: 31.1294 (0.122076)

standard deviation: 20.2662 (0.0794754)

kurtosis: 1.81201

skewness: 1.18339

Image statistics:

Overall:

min: 0 (0)

max: 252 (0.988235)

mean: 80.9815 (0.317575)

standard deviation: 52.6801 (0.206589)

kurtosis: 2.82689

skewness: 1.77181

Rendering intent: Undefined

Interlace: None

Background color: white

Border color: rgb(223,223,223)

Matte color: grey74

Transparent color: black

Compose: Over

Page geometry: 1392x994+0+0

Dispose: Undefined

Iterations: 0

Compression: None

Orientation: TopLeft

Properties:

date:create: 2012-09-09T15:29:26-04:00

date:modify: 2005-05-15T22:07:34-04:00

dc:format: image/tiff

exif:ColorSpace: 4294967295

exifixelXDimension: 1392

exifixelYDimension: 994

photoshop:History:

signature: 49893a961e750337e0182db3fd32c3f90fb2a6881d6ab38ed20b6667216aad81

stRef:documentID: adobe:docid:photoshop:cceffe26-c5ab-11d9-9048-a3fb3729e985

stRef:instanceID: uuid:cceffe27-c5ab-11d9-9048-a3fb3729e985

tiff:artist: (redacted)

tiff:endian: lsb

tiff:photometric: RGB

tiff:rows-per-strip: 1

tiffoftware: Adobe Photoshop CS Windows

tiff:timestamp: 2005:05:15 22:07:20

tiff:XResolution: 72/1

tiff:YResolution: 72/1

xap:CreateDate: 2005-05-15T22:07:20-05:00

xap:CreatorTool: Adobe Photoshop CS Windows

xap:MetadataDate: 2005-05-15T22:07:20-05:00

xap:ModifyDate: 2005-05-15T22:07:20-05:00

xapMMocumentID: adobe:docid:photoshop:300212f9-c5af-11d9-9048-a3fb3729e985

xapRights:Marked: True

Profiles:

Profile-8bim: 6976 bytes

Profile-iptc: 24 bytes

unknown[2,0]:

Byline[2,80]: (redacted)

Profile-tiff:37724: 3984008 bytes

Profile-xmp: 6717 bytes

Artifacts:

verbose: true

Tainted: False

Filesize: 8.149MBB

Number pixels: 1.384MB

Pixels per second: 46.12MB

User time: 0.030u

Elapsed time: 0:01.030

Version: ImageMagick 6.6.9-7 2012-08-17 Q16 http://www.imagemagick.org

identify: (redacted).tiff: unknown field with tag 37724 (0x935c) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/706.'

`
I note again an error at the end, similar but different.

When I attempt 'convert' with these 2 files, I get:
`

convert: (redacted).tiff: unknown field with tag 11 (0xb) encountered.'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/706.

`
and
`

convert: (redacted).tif: unknown field with tag 37724 (0x935c) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/706.

`

...respectively matching the unknown field tags from 'identify -verbose' listed above. Conversion still DOES complete. However! If I convert the .tiff to a .jpg the resulting image is recognized and displayed by Zenphoto. If I 'convert' that .jpg back to a .tiff, the 'identify' warning goes away but Zenphoto still does not show an icon, just a text-link to the image view page -- the same issue I described originally. On a whim I also converted a working .jpg into a .tiff, with the same results. In each case a thumb is generated in the cache folder, which I can view with 'image viewer' and which appears essentially normal (colors are a bit off, but fine for a thumbnail), with the exception of Silverfast generated tiffs where a black (this became apparent when I changed the background color of the viewer from black to white - maybe a layering issue, unrelated to Zenphoto) but appropriately sized thumb is generated. But no TIFF from any source I have tried has been visible except as a text hyperlink in Zenphoto. Since using 'convert' to generate the .tiff doesn't lead to it working, I'm at a loss.

(Sorry about formatting, it didn't come out cleanly and every edit I seemed to be conflicting with whatever this forum software was doing to the post. I'll re-post from scratch if it is unreadable/on request.)

It seems to me that there are really two issues:

1. ImageMagick does not produce correct thumbnails for images processed by SilverFast. I didn't see anything immediately out of place from the info you posted, but I'm far from on expert on the format. Given that the issue persists on the CLI, I think you'll need to check on the ImageMagick forums for help.

2. TIFF files are not viewable in the browser. I've done some research and it seems that most browsers (maybe all?) are unable view TIFF files natively. This isn't something that Zenphoto can remedy and will almost certainly limit the format's usefulness to potential viewers.

In general, it's usually advised against using TIFF files directly on the web and instead to convert them beforehand to a more generic format. It seems to me that this will be the best option since the TIFF format seems quite complex and varied.

Well, I can view these TIFF's with Firefox, including the 'full image' from Zenphoto, once downloaded, and the cached thumbs & downsized versions if I choose to open them *directly* with Firefox. But this appears to be a benefit of the mozplugger plugin. The thumbnails just don't show up in album view in Zenphoto, and the downsized versions, while generated in cache, don't show up in the image view. So for #1 I agree, and that seems to be a separate issue. But for #2 it seems to be a matter of how Zenphoto is trying to present TIFF's to the browser -- at least, probably not an issue with imagick/imagemagick. That said, it may be a low yield find-and-fix issue, and personally I don't know where to look (theme files, or somewhere else?).

I do agree with the general concept of avoiding TIFF files on the web, but on the other hand the ideal end user solution is one which absorbs what it is given and is able to manage and display it. TIFF is still a fairly common format, though somewhat niche, and being able to make them viewable and available, with minimum setup effort, would be ideal. It does seem so so close, as the files are there and otherwise viewable (although black from Silverfast). As it turns out I have some collections which I don't want to make available by way of Zenphoto, as well as a number of videos which are obviously impractical to make available in native formats, so the inconvenience of separately storing original TIFF's along with original videos and making some jpg's available with Zenphoto would be somewhat mitigated. Unless/until I or someone can figure an alternative, I may either do that or activate one of the plugins to allow a placeholder thumbnail and warn my limited viewers -- maybe both, with a viewable jpg alongside. Kludgy though.

I don't know how most other similar applications handle this but one I used previously (Synology PhotoStation), while frustrating enough in other ways to move to an alternative solution, would perform format conversions for display/streaming while maintaining the original file. Starting to run into a tangent with that, perhaps.

Thanks for the input!

Ahh, I think I understand what's going on. When viewing an image independently, the browser uses whatever works best, which would be mozplugger. In a Zenphoto page, however, every image is displayed using an `<img>` tag, which forces the browser to attempt to display it natively. I suspect that these images would work with the `<object>` tag instead.

To accomplish this, it should be possible to create a new plugin `class-tiff` which would output TIFF files with `<object>`. If you're confident trying to do this yourself, see `zp-core/zp-extensions/class-WEBdocs.php` for a prototype to follow. If not, I'd suggest opening a feature request and I will take a crack at it.

Well, I just stumbled on another still very kludgy option. So I went and added 'TIFF' as an extension using class-AnyFile. This evidently allowed Zenphoto to use an identically named jpg in the same directory for thumbnail purposes (leftover from testing earlier), although when you mouse hover over the image the link claims it's a TIFF. I don't think it really is. I think this is the same functionality available for video thumbnails in Zenphoto. Unfortunately, though I only just stumbled on it and haven't toyed with it yet, in the image view it shows as still thumbnail sized -- but clicking on the full image gets you the TIFF.

...

After a few minutes of playing with naming in the cache folder, I could "fool" Zenphoto into using a larger jpg image as a thumbnail. Zenphoto automatically squeezed it into a thumbnail sized space in album view, but showed the larger jpg image in image view (rather than just a thumbnail), then if that image was clicked it took me to the full sized TIFF download.

For album view thumbnail purposes it might be a useful way to thumbnail a link to the full sized TIFF so one has an idea what they're getting before they get it, but it isn't a solution as it (I think) is really just showing the jpg anyway, and doesn't display a normal image view page (so one can't see an intermediate sized version, at least not without a painstaking and wholly impractical process of manually moving/renaming files into the cache folder).

What you describe is indeed the video thumb functionality and if you need to deliver tiff fine data that would be a good way to workaround this.

Just to note is working on my test site:
http://zenphoto.maltem.de/Test/
They do display in Safari 6 (since that uses system resources like Quicktime it probably displays nearly everything) and Firefox as well. Those are Photoshop CS3 saved files with and without LZW compression.

I don't have Silverfast but couldn't it be something that it generates? Wrong meta data or else?

Btw, TIFF is by no means a niche format! It is actually widely used in the print area because of the lossless compression abilities.

As acrylian noted above, that functionality is the same as the video thumb functionality.

QuickTime definitely will allow for TIFF viewing, so any application compiled against it should work, which would mean that OSX browsers should work.

To get it working in all browsers, you'll want to do more than to add the TIFF extension. You should be able to use `class-tiff::getBody()` to output an `<object>` tag. That should work on all systems, including those with QuickTime.

Didn't see your post last night until I finished mine, then couldn't log back in to reply.

A `class-tiff` plugin sounds like a more definitive solution, without messing with core functionality that otherwise works well, and minimizing steps needed by a user. With a prototype I might have a chance, but my current talents are decidedly not in the area of any kind of code, and time isn't nearly as available as it used to be. I'll post a request if I stall soon.

Thanks again!

Prototypes are the class-***** plugins you already modified one. All those are extensions for formats graphic libaries don't support directly. With those you can make Zenphoto "catalog" any kind of file if needed. Of course for specific thumbs you always will need to follow the video thumb way.

There are definitely differences in display among current browsers, now that I'm testing with different ones. Chrome shows placeholder boxes instead of the text links Firefox was giving. Internet Explorer successfully displays TIFF thumbnails in album view, and an almost normal image view page, although a little imperfect (using 695px or 795px resizes sometimes causes those images to fail and a placeholder box shown on the image view page) -- however, I had previously installed AlternaTIFF ActiveX plugin. I started to test with Safari but seem to have broken something on my site which I'll have to fix later -- or maybe too many failed logins from Safari, heh. Anyway, it's helping to get a better understanding of this.

I can't really help with the development questions, but I can chime in on the importance of supporting TIFFS - I've just created a ZenPhoto website to collect and display historic photographs for a small community in Maine, and very much want people to contribute their photo scans as TIFFs - it's a great archival format that can be reprinted, resized, reused without any quality loss from compression and recompression.

I think the ZenPhoto TIFF web display should still be JPEG, which ImageMagik can happily do - it's how the ResourceSpace photo management system does it: you upload a TIFF, ResourceSpace saves the TIFF and spits out several different sizes of JPEG, then displays the small size JPEG and offers all the others for download.

My users are definitely aware of TIFFs - my first batch of photos was four CDs of scanned photos, saved as TIFFs, which I had convert to JPEGs to upload for the previous version of ZenPhoto.

You can check out the website in question at:

bpoolphotos.com

I've been considering adding a ResourceSpace subdomain to allow users to upload TIFFs - which we really need if we're going to be an actual photo archive! - but if I could handle it all within ZP it would be so great! Much better community building with comments, ZenPages, and great galleries.

I've made http://www.zenphoto.org/trac/ticket/2244 for creating such a plugin.

Awesome. Saw this upon checking in before going to create a ticket myself, so I'm glad to see it has a little traction at least. I've had woefully little time to learn, experiment, learn some more, etc., and have had essentially zero success on my own. I hacked a few existing plugins just to try proof of concept in using `<object>`, with no success (though extremely limited knowledge as far as what I was doing). But it sounds like a thought on why that wasn't working may have already come up on the ticket. If I come up with anything concise that might be specifically useful I'll post it there.