Is there a way to maintain the quality as a deepzoom image zooms?

I've never used deepzoomtools.dll, so I'm not sure what it's capable of... but I'm sure you can create deep zoom images using png files for lossless tiles.

I'm curious why you chose a tile size of 254 pixels?

Thanks for the reply. Maybe for the tileformat I'll try using ImageFormat.png and see if that is any better as the users are uploading jpg files only, not png files.

I'm using tilesize = 254 as opposed to 256 at the recommendation of another individual in another forum. I was having a problem with lines between the tiles when I'd create the deepzoom images dynamically with deepzoomtools.dll. It looked really bad as you zoomed in because you could see all of the square tiles. When I changed it to 254, they went away. Now, there could have been a few more variables as well as a new version of deepzoomtools came out, but I think I tested it on the original version of deepzoomtools that was having the problem and it fixed it. Then I upgraded to the latest version of the dll.

He said:
In order to get rid of the seams (lines) between the tiles you should set tileOverlap to something bigger than 0, ideally 1:

Dim
ic As
New
ImageCreator()

ic.TileSize = 254

ic.TileFormat = ImageFormat.Jpg

ic.ImageQuality = 1

ic.TileOverlap = 1

It can also be beneficial to set TileSize to 254 so the resulting tiles will not exceed 256x256 and therefore have better performance characteristics due to texture buffering.

I had tried tileoverlap set to 1 in the past and it hadn't fixed it, but changing to 254 and tileoverlap one did get rid of the seams.

I'll write back if saving the uploaded jpg to png format gives better image quality in the final dzi.

So I tried it with imageformat.png and it doubled the size of the deepzoom image files on disk and essentially just added more color to it. I couldn't see any real difference in quality.

Just a few thoughts around ideas already mentioned here:

PNG files are all about compressing an image's size as much as possible within the parameter of keeping every single pixel exactly as it was originally. This is referred to as lossless compression. Photos do not really compress well using this method but a PNG will usually reduce the size of a purely uncompressed (and therefore trustworthy when image purity is your first concern) image format such as BMP. In other words PNG is primarily about guaranteeing that your pixels stay exactly as you made them (incredibly important when you just spent hours producing an illustration or cleaning small details of an image in Paint Shop Pro or Photoshop or the like) and secondarily about making that perfect image as small as possible. PNG's compression really works best for simple images like text or line art when there are large portions of the image that are the exact same color or when there are linear gradients used where all the rows or columns the entire breadth of the image change in exactly the same way.

By contrast, JPG is able to compress filesizes much more because it is throwing out all sorts of data each time you save. Simply by opening a JPG in an image editor and telling the program to save it (recompress it) you will be making it worse than it just was, even if you did not edit it in any way. You could spend a day doing nothing but opening a JPG and then saving it again. Each time it would become worse than the last time - losing colors, losing detail, becoming increasingly blurry and more filled with static and aliased edges with each subsequent save. The JPG quality setting really only changes how fast you are corrupting your image. If you repeatedly save a JPG at 80% quality, the first time will be 80% of the original image, but the second save will only be 80% of 80% of the original image quality and so on.

In your case it may not matter too much since you are simply 1) receiving an original image from your user, 2) compressing and throwing away tons of detail by resizing it to the absurdly small 1024 pixels in the largest dimension, and 3) recompressing each tile of that now-tiny version of the original image given to you. This means you are really only losing quality due to JPG compression twice and due to reducing the resolution once.

Aseem's suggestion to limit the viewer's proximity to the pixels is spot-on, but I just can't believe that you're really resizing these images to a maximum of 1024 pixels wide|high and then trying to make a deep zoom image out of the result. You're not giving people any room to zoom in at all. If they took the time to upload the full photo to you, you should have the guts to convert the full resolution to the deep zoom image. I'm sure that you're thinking, "That will drive my bandwidth costs through the roof! There's no way I'm doing that, Nate. Go run your own server and I'll run mine!". Well, fair enough. I will say this, though; Have you considered that when you convert a file to a DZI, there is almost no chance that any appreciable percent of your users will ever download the entire deep zoom image pyramid? This means that your server will only ever serve up small chunks of each DZI so that even if I came along and uploaded a 21 megapixel horizontally oriented photo to your service and when you converted it to a DZI (without resizing it to 1024 pixels wide first) it resulted in a 10MB DZI (I'm making up numbers here), I think that upwards of 90% of your visitors would only download perhaps 10% out of the entire DZI and that's only if it were an exceptionally interesting photo. Hosting DZI's is a different beast altogether than hosting other sorts of files where the entire file must be loaded before the user can view it at all. It's true that 1MB for a single image is a lot of bandwidth per image, but you must remember that the longer a person is intrigued by zooming around one image, the less time they are also spending using bandwidth on other images, meaning that it should be roughly the same bandwidth per time spent on your site as usual. You will have a few users who go crazy and want to zoom down as far as they can and pan around every last detail of each image that they like but I think that the average person gets tired of this very quickly. Very soon, even though they like that all the detail is available to them, they will start to zoom down onto the one or two details in a photo that matter to them and then move on to the next one. Having all the images available in high quality means that they can come back any time and quickly look at a different part if they want to, but you will find that people will manage their time so that they can accomplish what they set out to accomplish effectively.

Perhaps it is more of an issue of "I have a limited amount of server space." than "I don't want my bandwidth to go up.". In that case I can only say that offering zoomable images that you can barely zoom into at all does not make sense to me as a user, especially if I uploaded a good high-quality image to your site.

That's enough from me, then.
All the best to you, tgakk.

P.S. Aseem, is there an option with Seajax and Deep Zoom to cache tiles on the user's machine? I know that the Photosynth team opted to not go this route (much to my dismay) but I thought that surely you guys would give the host an option of whether to do this or not.