TIFF image support?

[toer]

By adjusting the cpg15x_filtypes table content (tif, image/tif, image; tiff, ...) manually (those cpg15x_filtypes entries were missing) after adding allowed_img_types=jpeg/jpg/png/gif/tif/tiff to cpg15x_config I succeded to upload a tiff picture. However, the Imagemagick conversion into normal_... and thumb_... pictures results also in tiffs -- I find it a bit weird to convert into web-useless pictures! Shouldn't they rather be jpegs in order to show up in browsers? Isn't there a rule always to convert into a decent show-format, irrespectably of the original's format?

Can such a 'jpeg rule' be implemented by altering some code somewhere in some php file?

[Joe Carver]

Can such a 'jpeg rule' be implemented by altering some code somewhere in some php file?

Probably, but it might be easier to use the Coppermine config.

1) Search and read:
http://www.imagemagick.org/script/command-line-processing.php

2) Config >> File settings   >> Additional command line options for ImageMagick

[toer]

Thanks for the hint! However, I got stuck. Can I modify the output format given that an Imagemagick construct will be, for example,

" /usr/bin/convert -quality 80 -antialias ******* -geometry 96x150  'albums/userpics/10001/pic_001.tif' 'albums/userpics/10001/thumb_pic_001.tif' "

where ******* should be replaced by relevant command line parameters? (My testing says that the command layout will be such, am I wrong?)

Should be easier to add command lines like perhaps " /usr/bin/convert thumb_*.tif thumb_*.jpg " -- could that be done?

[Αndré]

Feel free to adjust include/picmgmt.inc.php. I haven't tested that, but it should be enough to adjust that line:

Code Select Expand

$thumb = $CONFIG['fullpath'] . $filepath . $CONFIG['thumb_pfx'] . $filename;

In your case a something like

Code Select Expand

$thumb = str_replace('.tif', '.jpg', $thumb);
should to the trick.

[toer]

Ok, that's the way to make the show  pictures. After

Code Select Expand

...
    $normal = $CONFIG['fullpath'] . $filepath . $CONFIG['normal_pfx'] . $filename;
    $thumb = $CONFIG['fullpath'] . $filepath . $CONFIG['thumb_pfx'] . $filename;
in picmgmt.inc.php I added

Code Select Expand

    $normal = str_replace('.tiff', '.jpg', $normal);
    $thumb = str_replace('.tiff', '.jpg', $thumb);
    $normal = str_replace('.tif', '.jpg', $normal);
    $thumb = str_replace('.tif', '.jpg', $thumb);
and the jpegs are generated.

However, they never show up. Could it possibly be that in the CPG code elsewhere the names are generated like 'normal_' . filename.ext and 'thumb_' . etc. instead of, in this case, more favourable 'normal_' . filename . '.jpg' etc? -- Because I cannot find more than the original file name saved in the DB. How do we proceed?

[toer]

Continued. This is a way also getting the pictures to show up. After

Code Select Expand

        $localpath = $pic_row['filepath'] . $pic_prefix[$mode] . $pic_row['filename']; in include/picmgmt.inc.php, insert:

Code Select Expand

    if ($mode == 'thumb' || $mode == 'normal') {
    $localpath = str_replace('.tiff', '.jpg', $localpath);
    $localpath = str_replace('.tif', '.jpg', $localpath);
    } Since the show pictures are jpeg copies of the tiff original.

It remains to activate exif use for tiff files if exif fields are assumed to be present in originals (also tiff). CPG appears to extract metadata only from jpeg, but I'll have a try.

[toer]

Here are modifications which make certain exif field useful also for tiff pictures, but must be checked and fixed for each and every field to be utilized.

This concerns the exif fields 'ImageDescription' and 'Copyright' only, which must be present in the $exif_info strings of 'exifmgr.php' and 'include/exif_php.inc.php' (lacked 'Copyright', I think). Next, change in 'include/exif_php.inc.php', at about l. 35:

Code Select Expand

//  if ($size[2] != 2) {
    if ($size[2] != 2 && $size[2] != 7) { // 2=jpeg, 7=tiff, accept both
Change in 'include/exif_php.inc.php', at about l. 50:

Code Select Expand

//      $exifRawData = read_exif_data_raw($filename, 0);
// Use PHP native 'exif_read_data' function instead and arrange these fields
// in a 'IFD0' sub-array as does the 'read_exif_data_raw' CPG function:
        $exifRawData = exif_read_data($filename);
        $ifd0 = array('ImageDescription' => $exifRawData['ImageDescription'], 'Copyright' => $exifRawData['Copyright']);
        $ifd0 = array('IFD0' => $ifd0);
        $exifRawData = array_merge($exifRawData, $ifd0);
So, now these two exif fields are equally accessible for tiffs as jpegs!

And to sum up, the only remaining tiffy anomaly for me so far concerns show-original functionality. A quick way to a at least temporary solution is, for example, to make a link of the file name in the file information table, to be used as any picture link.

Hope this was informative for someone, and that full TIFF support will be included soon in Coppermine, perhaps including 'exif_read_data' of PHP?

[dazzin]

I do not understand why the thumbnails are saved in the original file type knowing that the goal is to display in a browser...

[toer]

Well, I think the intention must be to make thumbs and show-size pics as jpegs. It's apparently that the tiff support isn't fully developed, or buggy, or whatever you may call it.

I have so far modded the code to fully support tiff (resized as jpeg) and additionaly automagic update certain file information fields versus certain xmp fields in order to have benefit of entered information through, for example, photoshop file information xmp fields (why xmp? because utf8! and most general).

This is for certain use, though, and the system needs a thorough revision to fully support tiff and perhaps xmp fields.

My DB <-> XMP updating (the one to the other depending on which is missing) is presenly in brief:

DB name <-> XMP name
title <-> Xmp.dc.description
caption <-> Xmp.dc.creator
keywords <-> Xmp.dc.subject
user1 <-> Xmp.dc.title
user2 <-> Xmp.dc.rights

for best use in my application. Generally, there should be an option to map any DB information field against any xmp field - that's my wish. And a genuine tiff support is the other wish, and today disk space is not very critical if LZW compression is applied. Originals may be shown by other means available in any operatin system, need not be the browser.

Just in case somebody is still looking at this forum topic ...

[dazzin]

Do you think it is possible to modify the source code to accept and generate thumbnails of all file types recognized by imagemagick? I would like to create a picture library which accepts all types of graphic files (eps, psd, tif, pdf, etc ...). Maybe Coppermine is not the good tools to do it...

[toer]

Do you think it is possible to modify the source code to accept and generate thumbnails of all file types recognized by imagemagick? I would like to create a picture library which accepts all types of graphic files (eps, psd, tif, pdf, etc ...). Maybe Coppermine is not the good tools to do it...

I think Coppermine has a basic structure that should allow for a revision by the development team in order to make it more image-type independent. Also, it's other qualities (basic functionality, simplicity, already good user modification tools) makes it a creditable candidate to get such extended properties.

That would include a revision of all code snippets (mostly repeated and often similar code that could be transformed into common functions) whith references to the reformated (from now!) always-jpegs -- and, another approach when it comes to showing originals (since, for example, tiffs cannot be directly put up i a browser but should rather be downloaded into another viewer). And a lot more. But that should be great and a competetive facility for Coppermine!

I tend to modify just that I need, now and then detecting cases where som more details must be changed, but to as a limited extent as possible, and with extended book-keeping in order to be well prepared for the next revision. Being general in this aspect would require a dedicated teamwork, I think.

To begin with, why not make Coppermine format-independent including at least tiff originals and test it out thoroughly, while preparing a general design that allows more file types to be inluded, similarly being convertted into into show-jpegs ... etc.?

Developers, what do you respond?

[Xtinch]

Sorry guys, but I've find this post, because I've have the same problem with the tiff files.
I'm trying to follow your directions, however, I've a doubt with following modification:

  if ($mode == 'thumb' || $mode == 'normal') {
      $localpath = str_replace('.tiff', '.jpg', $localpath);
       $localpath = str_replace('.tif', '.jpg', $localpath);


This must be done in  picmgmt.inc.php or in: functions.inc.php


Because I've didn't find the location of the code where you have stated,  and I did find it in functions.inc.php.

thanks in advance.

[Αndré]

I assume it's just a typo. Apply the code change in include/functions.inc.php.