Libtiff goes offline
madfileformatscience.garymcgath.com
madfileformatscience.garymcgath.com
Why not involve libraries in the effort? They could keep a "master" copy and github.com, gitlab.org, SF.com, or whoever else comes next can host development versions.
It has been on my list to integrate https://github.com/joeyh/github-backup with https://github.com/ArchiveTeam/ArchiveBot.
There is a need for an organization that is willing to host established but small and unfunded projects like libtiff, libpng, zlib, etc., and give them some minimal organizational backing in the interest of continuity (so no github). Somewhat similar to, but more general than, what the Network Time Foundation is doing for ntp and related projects.
This was for iOS 1.1 though, not iOS 1.0, as it was not encrypted and was never really locked down. It was Apple's choice to release iOS 1.0 without the security enabled that made further jailbreaking efforts much more straight-forward, because there was extensive knowledge of the file system.
This was all well before there was an App Store, and when Apple's public position was that they'd never allow third-party software on their platform ;)
http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.h...
Arch `libtiff` provides libtiff ABI 5, while `libtiff4` provides ABI 4.
The real issue is that a lot of people rely on this and nobody is willing to put anything back toward it.
Apparently we have learned nothing from the OpenSSL debacle.
However looking at the mailing list, it seems this domain is not controlled by the developers.
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.
As for a site which cares about archiving, they can almost certainly add a tag for every commit they slurp up (making sure it doesn't get hit by the git gc). Though, I'm fairly sure that you can just configure your git instance to never garbage collect.
Is this a real problem or a theoretical problem?
That's a throwback. I looked it up and apparently UNC's Sunsite turned into http://www.ibiblio.org/about/
There are a couple of other Sunsites still up. This one looks like it has not been updated since 1997: http://sunsite.ubc.ca/
/me cringes in fear of a left-pad moment -- what distros can't be built now?
Example for my distro, gentoo[0]
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
It's a shame since the compression technology was impressive and j2k would also have made a great progressive image format had browsers supported it.
Texture data for some videogames
Portable format for layered composites (a la Photoshop)
This is very helpful for processing which treats each pixel as a sample of the scene, such as computational microscopy or remote sensing. I've always wondered if that had something to do with why it was hosted at remotesensing.org.
Viewers of libtiff often treat it like PNG/JPEG, but good Tiff viewers can leverage this functionality. Typically few batteries are included.
Tiff is kind of a cross breed between structured portable formats (HDF5/NetCDF) and imagery.
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)
It's being slowly replaced by HDF5 for some applications.
But all of the features you mention above are tunable and are in practice perfectly fine with TIFF containers.
Yes, but for most image formats they aren't defined. They are for TIFF.
The problem, of course, is that if you use an exotic TIFF feature, very few TIFF readers will understand you.
https://en.wikipedia.org/wiki/Digital_Negative DNG is based on the TIFF/EP standard format, and mandates significant use of metadata
.PSD is tightly tied to Photoshop's internals, and .xcf is tightly tied to Gimp's internals. (The Gimp core developers explicitly recommend against using .xcf as an interchange format, even though the format has a fairly complete publicly available spec.) I've seen .gif images with multiple frames used as images with layers, but that forces every layer to have the same resolution, and of course limits you to an 8-bit color depth.
Supposedly the Gimp and Krita devs are collaborating on a new interchange format that will support things like layers, but I haven't heard any news about that in years.
Unfortunately, it looks like there's no support for it in Photoshop, and I doubt that's likely to change.
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.
Not all images are taken by cameras using 3 channels.
The PNG-format supports them (up to 4 channels) however not all apps know what do with them.
I work for a company that makes workers' compensation software. I don't know of anything in our product that actually generates new TIFFs, but we've got plenty of old ones bumping around that were either uploaded by users or imported from other systems. I end up interacting with TIFFs one way or another every other month or so.
PNG offers only a tiny subset of what's possible with TIFF. Note that TIFF supports multiple compression formats, lossless and lossy, multiple sample formats and sample counts, very flexible organisation of data layout etc. PNG offers a small number of sample formats, fixed layout and compression, and none of the higher-level TIFF features.
PNG is simple and easy to use. But "better" is subjective and by most objective measures it's inferior to TIFF.
Nor clipping paths.
For print, there is not really an "open" alternative that is as good as TIFF.
What am I saying, that place[0] exists. Developers shouldn't have to shoulder the burden of hosting their code if they don't want to or don't wish to weather the expense. It certainly seems in this case they couldn't pay for self-hosting (or friend-hosting or whatever this is). I do suppose it is difficult to move development to a new system though(CVS to git).
This is simply a permanent problem. Archive.org and to a lesser extent IPFS are viable solutions for archiving, but _contingency_ plans are I think the missing component here. Pray for the best but prepare for the worst.
Gitlab et al are growing, and now AWS has its own integrated solution, but I don't see Github going anywhere for a very, very long time. (Barring catastrophic happenings, of course.)
The question is, can we trust an entity like that to remain trustworthy through decades? Turns out SF.net wasn't trustworthy through all of that time, even if they were in the beginning, and seem to be sincerely trying to be trustworthy again. So, if we put all of our eggs in one basket, we better be really confident of that basket. We could have lost every OSS project website, rather than just one, if an entity that we trust today becomes untrustworthy tomorrow.
Yes, GH does a lot of things right, including generally making it easy to export data form their apps in a reasonably vendor-neutral form. But what happens when GH runs into financial trouble like SF did? Do we want just about every project out there to have to struggle to do something with their GitHub issues?
There are issues with having open-source projects maintain their own infrastructure, but I think it's the right thing to do wherever possible. It makes them truly independent in a way that a GitHub repo can never be.
One day, this will have only existed. Until then, they should host the repository on Google Code.
Mandating github for everybody is a Bad Idea.
I am receptive to this kind of argument, I am honestly curious for specifics.
See if there's a better solution.