The code is now being hosted at http://www.simplesystems.org/libtiff/ with a mirror site at http://libtiff.maptools.org/ .
There is also a github mirror at https://github.com/vadz/libtiff .
Libtiff goes offline
71–80 of 121 posts
Re: Libtiff goes offline
#72Earlier quoted context omitted.
I won't use github for my own projects because I don't agree with their politics. (If you're ok with them, good for you. I won't stop you.) Mandating github for everybody is a Bad Idea.
What do you disagree with? I am receptive to this kind of argument, I am honestly curious for specifics.
That's irrelevant, really. Just that standardizing on a particular business for all repositories will never please everyone.
See if there's a better solution.
Re: Libtiff goes offline
#73Earlier quoted context omitted.
A git HTTP archive can be crawled and archived in principle. They might well be doing this already with github and elsewhere just through the normal course of their operation.
https://github.com/joeyh/github-backup
Re: Libtiff goes offline
#74Re: Libtiff goes offline
#75Re: Libtiff goes offline
#76Tiff? That is a format I haven't heard in a long time. edit: to everyone replying. TIFF is awful. We have lossless compression now (read PNG) which is at least a billion times better. We shouldn't use it for anything in this day and age. Hell, just DEFLATE your TIFF and call it a new format. It will be better than TIFF
> Hell, just DEFLATE your TIFF and call it a new format
You don't have to call it a new format, TIFF has supported lossless compression for decades now https://en.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag
DNG is also based on TIFF, so I can imagine people might use libtiff to read DNG headers.
Re: Libtiff goes offline
#77Earlier quoted context omitted.
See my edit. Also, when you are doing image processing, operating in scanlines is usually the least performant way of doing things, hence whey we have texture compression formats (even lossless ones) which do block encodings. TIFF has no reason for existing in my opinion.
TIFF supports many useful features for processing very large images. Tiled compression, storing channels in contiguous hyperplanes or on a single image plane, multiple levels of detail, custom compression codecs (lossless or lossy), sparse images, arbitrary bit widths, and permits storing arbitrary metadata with the data. Viewers of libtiff often treat it like PNG/JPEG, but good Tiff viewers can leverage this functio…
I don't doubt that you can have a library that provides all those features. All those features can exist for any lossless image format. My point is that as far as comparing image formats goes, the capabilities of the frontend library isn't a useful metric for evaluating the format itself which, in my opinion, can optimize for the following traits:
1. On-disk size
2. Compression/decompression speed
3. Access speed (for use in image analysis algorithms, editing, compositing, etc)
4. GPU friendliness (which operates in warps on small blocks of contiguous pixels in image space)
TIFF doesn't really optimize for any of these (not even #2 since in-memory decompression can be faster than paging uncompressed data from disk)
Re: Libtiff goes offline
#78Tiff? That is a format I haven't heard in a long time. edit: to everyone replying. TIFF is awful. We have lossless compression now (read PNG) which is at least a billion times better. We shouldn't use it for anything in this day and age. Hell, just DEFLATE your TIFF and call it a new format. It will be better than TIFF
TIFF is typically used as an intermediate uncompressed memory format for almost everything in images. Your png library is probably uncompressing png images into TIFF images internally. Your printer probably translates whatever is given to it into a TIFF image to print, your scanners probably use TIFF as a raw format to translate into something else. Even camera RAW images are probably using TIFF in some way or anothe…
> Even camera RAW images are probably using TIFF in some way or another
https://en.wikipedia.org/wiki/Digital_Negative DNG is based on the TIFF/EP standard format, and mandates significant use of metadata
Re: Libtiff goes offline
#79A bit tangential, but I just noticed that in the Arch Linux repos, `libtiff` is version 4.0.6, but there's another package called `libtiff4`, which is version 3.9.7. I don't suppose anybody here might know the rationale behind this bizarre version/naming paradigm?
As chrisseaton said, version numbers aren't necessarily ABI numbers.
Arch `libtiff` provides libtiff ABI 5, while `libtiff4` provides ABI 4.
Re: Libtiff goes offline
#80Earlier quoted context omitted.
A history goes with every copy. You still need a protocol for determining the history.
If you have a maintainer who signs their commits, you trust their signatures and call it a day. Go with the latest commit and that tells you the history that they have cryptographically claimed is "correct".
One problem I see there is that, with git, you still have to take care that you keep around all the commits that at any given point in time were declared "correct".
For example, if a commit is amended and force pushed out to remove a backdoor from a popular package, a site interested in the history of the library will want to ensure that the faulty commit stays around.
I'm not even sure that is 100% possible, but it, at least, will take some careful git configuration.