Odd failure tiling large tif or PSB

I want to see if krpano is right for me so I am attempting to make tiles of a 155000 x 7498 (1.2gp) image on Linux 64bit. On a TIF saved from photoshop, the first row or rows of tiles are OK, but at a scan line that may or may not be the 2 billion byte mark, it switches and each pixel is displayed forever repeating downward, even the watermark pixels. I have attached a crop from an example. I also tried smaller tiles.

So I saved the file into a PSB and unfortunately all I get is a big set of black tiles (with watermark.) I am aware that some older programs can't handle TIFs larger than 2gb, but this is the latest krpano tools just downloaded today. Photoshop CS2 is of course able to read and write the 4gb TIF and 6gb PSB.

It would be nice if kmaketiles could handle PNGs. For large panos, PNG with its compression often is able to come in under 2GB when TIF can't, and as such is much more compact than PSB or other formats. AutopanoPro makes PNGs and that's my usual choice when the width is more than 65K. Converting to PSB is slow because it takes Photoshop a long time to load and save these images. Another option, perhaps better in its way than handling just PNG would be to handle PPM, because the PBM toolkit has tools to stream out just about any format as PBM out stdout. Well, not PSB I think, alas. There is a pbm splitter, pamdice, which outputs ppm files that can then be converted to jpeg, I suppose, which could be used instead of kmaketiles.

My command line is: kmaketiles /local/photo/pano/bm10/dota-maga-360.tif "dt_%v_%0h.jpg" 2000

On another note: I see talk of krpano working with an already tiled image but don't see much more detail? Is krpano able to put all the tiles into a single file so you don't have to have a directory with 400 files in it? That would be nice? Presumably one could embed the seek locations of the tiles in the file into the xml or the start of the file, and then the tiles could be fetched with the HTTP "Range" feature. How does one do this?

Thanks for the info. I had suspected this was the issue. I believe the programs that write large TIFs including photoshop just use segments that are smaller than 2GB and thus avoid having any offsets that are too large. As noted photoshop is able to read the file. While it would be good if libtiff or krpanotools could read them, I understand that is extra work. PNG helps somewhat, but it too has a 2gb limit. The hard truth is that "keeping it below 2gb" is simply not an option on many beyond gigapixel photos. Very rarely with TIFs, sometimes with PNG but sometimes it's just not possible at all.

But I suspected that the 2GB limit was the issue which is why I also tried the PSB. Photoshop wrote, and also can read the PSB so it seems to be in order, but kmaketiles gives nothing but black tiles. Alas, I can't really send you a 6gb sample image to try, but if you might try to write a 155000 x 8000 image in Photoshop (CS2 if you have it) and see if you can duplicate the problem.

As noted, support for PPM format, which is a simple format that supports all sizes and depths and has many free tools and libraries available to work with it, would then let you read all the formats you currently can't read with this tool. I am going to hack together my own option to see if I can make it work.

I understand doing a CGI to fetch fragments of files from a giant file and it makes some sense. The approach with HTTP ranges has the nice feature that the person need not install any CGI on their web site. It also offers more -- if you were to do the tiles in a nested sort of fractal arrangement, you could find that you could fetch larger stretches at once. For example, if you have one tile, and the tile to the right comes after it you can fetch them both together if you notice that. But the main goal is to avoid having to have tons of files. I have many hundreds of panoramas up and I hope not to have to put up hundreds of tile files for each. With a progressive jpeg you might even be able to seek into the middle of it to pull out a tile. But that's for the future, I suppose.

In the meantime let's see if we can figure out what is happening to the .psb

I did a zip compressed TIF. Not quite as good as a PNG but it fit in 2gb, and that confirms the problem with the TIF in this case was the 2GB limit. I do not believe I put any levels in the PSB -- there are no levels in the image, but I will try to check that later. Photoshop CS2 for a long time was the only one to run well on linux. Word is that CS4 is now decent on linux, and there is even hope for cs5 if you can install it.