Tif issues

[dfroelicher]

Ok so I cant seem to get DCP to load a tiff in to save my life

the error code coming back at examine content is
"Error (Magick: Failed to read custom directory at offset 5569812. 'TIFFReadCustomDirectory' @ error/tiff.c/TIFFErrors/561)"

ideas?

[carl]

Hi, are you adding a single TIFF or a directory of them? What precisely are you clicking to cause the error?

[Carsten]

Reading this, I just tried to load a few CMYK TIFFs in 8 and 16 bit, and it seems DCP-o-matic is misinterpreting the colour. Guess not many people are using CMYK TIFFs as a source for DCPs, but may still be worth looking at. No errors importing them, though.

Mac version 1.78.3


- Carsten

[dfroelicher]

single tiff, just add file to project and I get the error in the initial examine of content sequence.

I would upload but they are too large 9mb at the smallest.

[Carsten]

Hmm, that's strange. Which platform and version of DCP-o-matic are you using? From the other thread I guess it is WIN7?

Where do these TIFFs come from? Any specific parameters? When you write 'pre-mastered', I assume they are already 1998/1080 RGB or something similar? Carl will comment on this, but I guess 9MB could still be sent through email, one should be sufficient anyway if you make sure that particular file also creates the same error.
You could also try to ZIP it before mailing, some TIFFs can become smaller ZIPed, some not.

- Carsten

[Carsten]

I should have known better, but I had an issue with single image both for still and sequence today, which is a rather stupid one, but can still cause confusion for other users: When you use images that have been stored/created/modified on a Mac and then transferred to a Windows machine through FAT, NTFS, etc. media, they usually carry their so called resource files with them. With every regular BMP file 'image.bmp', there will be a second small file '._image.bmp'. This has the BMP, TIF, JPG, etc. extension, but is never a valid BMP, TIF, JPG, etc, file. DCP-o-matic will try to import them due to their extension, and will fail, even if there are other, valid images in that same directory. The error may suggest you have an invalid image file, or that DCP-o-matic is not able to import a specific format - but in reality, these '._*' files simply are no image files at all. With an image series of 12.000 TIFs, you will also have 12.000 corresponding ._*.TIF resource files.

The solution simply is to NOT select all images, leaving out all files beginning with ._, or to delete these before importing them into DCP-o-matic. Since the 'Add directory' does not show any content to be selected in the directory open dialog, the only option in this case is to open that directory before in file explorer, select all '._' files and delete them, then proceed with DCP-o-matic. It doesn't hurt deleting these files, even if you bring these files back to a Mac.

I had similar issues years ago when transferring MP3 or JPG files to non-Mac systems, so I built little Automator tools, 'Clean&Eject-Droplets', that allowed me to drag a portable volume on them, and the droplet would erase all '._' files on them, then eject the media.

So, the same will also happen with video files, audio files etc. coming to a windows machine that way. I believe in Linux the OS will simply hide the files, as Mac OS X itself does.

So, make sure you do not feed '._' files to DCP-o-matic. This is no issue when working all Mac.

- Carsten

[carl]

I've changed my local copy of DCP-o-matic to ignore files that start with ._
I can't see a problem with that ...

[Carsten]

Yes, I think that won't cause any problems. It's especially important when adding directories/image sequences, because the folder selector box in that case actually does not show any individual files at all, so you can't see these resource files causing the error.
This is different when using 'Add file', where at least you have a chance to see those files before choosing them.

- Carsten