IMServer:Uploader: Difference between revisions
(One intermediate revision by the same user not shown) | |||
Line 6: | Line 6: | ||
[[File:IMServerMultiresNamingConvention.png | Naming of images for multiresolution representation]] | [[File:IMServerMultiresNamingConvention.png | Naming of images for multiresolution representation]] | ||
== Uploading images into database == | |||
* Either dice the large images first and store in .mrj (Multi-res JPEG) format and later read from the MultiResolutionJPEGSource and insert the binary tile chunk into database one by one. | |||
** This results in unnecessasry writes on the disk | |||
* Or Start the dicing process, and without any disk access, keep inserting into the MongoDB as and when every tile chunk is generated. | |||
** Currently this will result in duplication of code | |||
== Image padding == | |||
If current image dicer is used for uploading images to the server, annotation polygons are incorrectly scaled across higher zoom levels and first zoom level. It is speculated that this behavior is due to padding of the input images so that their size (in x and in y) is increased to the next power of two. So that each next level of resolution can be easily calculated by division of two. | |||
Thus, the number of desired zoom levels can be easily computed once the size of screen is fixed. | |||
6 | |||
i.e. if the screen resolution is considered to be 512 height. Then the lowest zoom (highest level) will have a tile no greater than 512. If the image size itself is < 512 height, then only 1 zoom level is sufficient. If the image size is say 20,000 then zoom levels will be 6. (512 * 2^5 = 16 384 and 512 * 2^6 = 32 768) | |||
== Upload to MongoDB == | == Upload to MongoDB == |
Latest revision as of 22:20, 24 January 2011
Image Dicer
Large images are split into multir-esolution representation
The files are padded to cover next power of two, and then
Uploading images into database
- Either dice the large images first and store in .mrj (Multi-res JPEG) format and later read from the MultiResolutionJPEGSource and insert the binary tile chunk into database one by one.
- This results in unnecessasry writes on the disk
- Or Start the dicing process, and without any disk access, keep inserting into the MongoDB as and when every tile chunk is generated.
- Currently this will result in duplication of code
Image padding
If current image dicer is used for uploading images to the server, annotation polygons are incorrectly scaled across higher zoom levels and first zoom level. It is speculated that this behavior is due to padding of the input images so that their size (in x and in y) is increased to the next power of two. So that each next level of resolution can be easily calculated by division of two.
Thus, the number of desired zoom levels can be easily computed once the size of screen is fixed. 6 i.e. if the screen resolution is considered to be 512 height. Then the lowest zoom (highest level) will have a tile no greater than 512. If the image size itself is < 512 height, then only 1 zoom level is sufficient. If the image size is say 20,000 then zoom levels will be 6. (512 * 2^5 = 16 384 and 512 * 2^6 = 32 768)
Upload to MongoDB
A simple mongo interface is created
<source enclose=pre lang="c">
- include <iostream>
- include <client/dbclient.h>
using namespace std;
class vtkMongoInterface {
mongo::DBClientConnection conn;
public:
// Constructor vtkMongoInterface() {}
// Operations possible int connect(const char *server = "127.0.0.1", int port = 27017); int insert(const char * name , int num ); int insert(const char * path, mongo::BSONObj obj); int query();
};
</source>