Ecw Jpeg 2000 Compressor Car

Morgan M-JPEG2000 codec is a multimedia compressor/decompressor which registers into the Windows collection of multimedia drivers and integrates with any application using DirectShow and Microsoft Video for Windows. Existing video software, such as Windows Media Player, Sony Vegas Pro and Adobe Premiere Pro, can utilize this codec to play, create and edit M-JPEG2000 files.Please note: M-JPEG2000 is completely different from M-JPEG, you can't manage M-JPEG files with M-JPEG2000 codec. If you're looking for an M-JPEG codec click. A new international standardJPEG2000 is a new international standard for image compression method and file format. This is the successor of the well-known traditional JPEG written by the ISO group Joint Photographic Experts Group.

Digital CinemaDCI (Digital Cinema Initiative) adopted JPEG2000 for video encoding of motion pictures. Current movie distribution and presentation from movie rolls is expected to be replaced by digital projectors that will play DCP (Digital Cinema Package) with superior image and sound quality. What is JPEG2000?JPEG2000 is the new international standard for image compression method and file format. This is the successor of the well-known traditional JPEG written by the ISO group Joint Photographic Experts Group.Contrary to the technology JPEG which used DCT functions, JPEG2000 technology is based on an mathematical algorithm called wavelets to compress image that provides high compression with image quality superior to all existing standard encoding techniques even at low bit rates.That’s the reason why JPEG2000 has a number of advantages over the JPEG Format.JPEG2000 Advantages vs.

02-Sep-10 10:28This starts a new thread, continuing from:There are some decisions that have to be taken regarding ECW vs. How do people in the Manifold user community feel about the two?Background:Manifold.net began supporting ECW when ER Mapper issued the SDK as source code.

ER Mapper wanted to keep it open as an alternative to JPEG2000 and to play on 'openness' as an alternative to proprietary compression technologies like Lizardtech.Manifold felt that to be a safe path to support, being indifferent between ECW or JPEG2000. Both seemed equivalent with no significant performance difference. All applications enabled with the ECW SDK were able to read either ECW or JPEG2000.The new SDK probably will not be available as source code. That changes things. If sources are not available that would put Manifold in the position of encouraging a proprietary compression standard over what we feel is a highly equivalent open standard, not something we want to encourage.That would also limit Manifold's interest in contributing code to ECW. Manifold engineers contributed assistance for Windows ports (the ER Mapper people were primarily UNIX people). We'd rather make those contributions to an open format like JPEG2000, especially if Manifold parallel know-how is contributed to utilize GPGPU to speed up compression and decompression.

If manifold.net parallelized JPEG2000 it would be decisively faster than ECW.From a compression storage perspective the two we think are equivalent for Manifold users, but neither is necessary any more with upcoming new Manifold products. The new products are so fast they are as fast or faster than ECW or JPEG2000 with plain, default images in plain, default.map files even with very large (tens of gigabytes) images. No need to mess with potential loss of detail or slow compression. It's faster to leave images in.map files and link to those from other.map files if you want linked images. We expect that as new products become available Manifold licensees will use either ECW or JPEG2000 only for interchange with legacy users.As far as we can tell, any ECW SDK-using application will continue to be able to read JPEG2000. Therefore, if Manifold can read any ECW but writes only JPEG2000 then any application enabled with the ECW SDK will be able to read that.Questions:1.

Is it OK for Manifold to continue reading ECW but to write only JPEG2000?2. Should Manifold provide open source code for read/write JPEG2000 if this takes away from other Manifold wishlist items?3. Should Manifold parallelize JPEG2000 (if this takes away from other Manifold wishlist items) or is current state of the art good enough if this format is used only for interchange?Sorry for cross-posting.

Please reply to this new thread. 02-Sep-10 11:01HiI dont have a problem with the first item.What are the other wish list items? What does it mean to provide open source code?

Does it imply that the community would have to provide R/W access to JP2000? I cant program.What would parallelizing imply for the regular users aside faster read using manifold 9.0?Manifold 9.0 should continue to natively read (import and link) ECW and JP2000.

In my case I dont have a problem if it only wrote JP2000 as I have other software that can do the conversion JP2000 to ECW.REgardsHow soon? 02-Sep-10 11:34What are the other wish list items? Some hints?There are thousands of wishlist items.

The question is are there other things you consider more important. If you can think of many other things that are important but don't care about the politics of open source you would vote for wishlist items in general and against spending extra effort on providing this as open source.What does it mean to provide open source code?

Does it imply that the community would have to provide R/W access to JP2000?No. This would be built into Manifold in any case. The question is if in addition source code should be provided, like with the image servers and geocoding servers. It is really a question about political feelings about compression formats.

If many people want to program their own applications that have read/write capability for JPEG2000 the answer is yes. If most people don't want to do that it is no. I expect very few Manifold users would ever program their own read/write uses of JPEG2000, but that some would be more interested in using it as a storage format if it were 'open.' However, on the other side if time has passed by this technology and it won't be used for anything but interchange with legacy programs it's a don't care. It depends on your preferences.What would parallelizing imply for the regular users aside faster read using manifold 9.0?Potentially much faster write.

The bottleneck for both ECW and JPEG2000 is the long computation required for compression/write. Like anything, asking for parallelization has a cost and should not be voted for on a 'why not just do everything?' Basis.Parallelization would also impact making source code available.

Pulling something out of the internal development infrastructure to be published as a standalone project can involve significant man hours, and might not be possible in the case of parallel code that depends too much upon other infrastructure. Another consideration is that manifold.net probably would not be willing to give away valuable GPGPU 'know-how' for free. 02-Sep-10 12:07Many of my clients (use ESRIstuff) so I mainly need to export to shapefiles and properly projected ECW/JPG2000 files. If I read you correctly then I think that opening code is not really that interesting to me and I would prefer that wishlist items (like better management of the legends in the layouts for better cartographic presentation) or (an SQL Query Builder) or a (better Raster Calculator) are my priority.Thanks for asking Mike. CheersBy the way I'd like to Beta 9.0How soon? 02-Sep-10 11:32Thanks for asking Mike.

In general I'd rather see other wishlist items worked on especially the ones I submitted.Will a 50 GB image in a map file be as fast as ECW? If so then I'd only need ECW/JPEG2000 for interchange and I suspect the current speed of version 9 would be fast enough for that (hopefully at least as fast as Globalmapper for exporting ECW).

If not then I'll have to decide whether to tile my images and see if that presents more or less issues than leaving them as ECWs.By the way, in the past I've used PCI Geomatics to create JPG2000 images and found them larger and slower (when displayed in Manifold) to ECWs coming out of Globalmapper. This is probably not a fair comparison of ECW vs. JPEG2000 but its what I could produce with those 2 softwares.

02-Sep-10 12:06Will a 50 GB image in a map file be as fast as ECW?That depends upon the specifics of the image and the compression, etc., done in ECW, plus the speed of the processor and other factors. Processor speed is important in ECW because there is more load on it, with a big difference between reading or writing an ECW.As a general rule 9 will be as fast or faster, plus it is read/write, selectable pixels, lossless and you have the convenience of working with an image like any other image. Zoom in, select pixels, change them if you want. No need to keep track if it is linked or local - works the same. 9 can connect to an external.map file just as fast as whatever is in its own.map file. Connect to it and it opens like any folder in the project pane showing components and folders it has. Use them just like they are local.

This facilitates using.map files as containers for images and other data you want to use.An ECW image is read-only and is usually lossy. A possible advantage of ECWs is they can achieve greater compression at the cost of being lossy. But in an era of $100 2TB drives I expect most users will want speed, perfect data fidelity and read/write dynamics more than saving disk space.It's interesting you have found JPEG2000 images to be bigger and slower than ECWs, at least for those two packages. I expect that would be OK if JPEG2000 was only used for interchange every now and then. 02-Sep-10 12:46Thanks for the info and the questions, Mike.

One of the most beautiful things about Manifold is its commitment to interoperability and open source. I imagine that it's one of the many important reasons GIS users like me choose it over other software.

I am in favor of Manifold sticking to its principles of supporting open source, first and foremost, and providing compatibility (read access) to a wide range of other formats.To answer your third question, if I understand it correctly, I do not think parallelizing JPEG2000 to provide faster read/write access is as important as the many more substantial improvements that users have discussed in this forum. JPEG2000 linking/processing is already quite speedy, and, as you suggest, if management of imagery internal to a.map project is more efficient, then any Manifold user will only use such a feature periodically.

02-Sep-10 12:14Lets see.1. Is it OK for Manifold to continue reading ECW but to write only JPEG2000?Yes, but because when I use raster files, they're usually on ECW format, I would require that manifold, keeps reading them (at least).2. Should Manifold provide open source code for read/write JPEG2000 if this takes away from other Manifold wishlist items?No. Because, I believe that a few solutions for this can be found already. However i do not know the amount of work required to do this so if it's doable without compromising Manifold's GIS development.3.

Should Manifold parallelize JPEG2000 (if this takes away from other Manifold wishlist items) or is current state of the art good enough if this format is used only for interchange?I avoid saving data on raster format, only when it's not possible to 'convert' it to drawing, i save it. So in my case JPEG2000 is used as a sort of interchange.Regards.Stay connected:Linkedin http://www.spatialmentor.com.

02-Sep-10 13:54Before I answer some questions on speed in a specific environment. What about reading a clipping of large ECWs over a slow (let's say 10MB ethernet) connection vs. JPEG2000 - a common situation for a team working with a file server. Are JPEG2000 equivalent to ECWs in this situation?ECWs use a lossy compression, yes. But the result often 'looks better' than the original because of a better contrast and the loss of unimportant details. Is this the same for JPEG2000?I can't test because when I export my 0 pixel ECW to JEPG2000 I get the same file size but I can't link this file.

Manifold tells me 'Can't create Component'. Is there a difference in size restriction?I need projection aware images and I read in manifold help that JEPG2000 'should not be treated as a projection-aware format'. Has this changed?Does the speed of manifold 9 with uncompressed or compressed images require a CUDA capable grafic card which is not present in many laptops?I have the feeling the present marked leader is not under pressure by manifold only but by the open source community as well. I guess it'll still be a long way to go together with this community until manfold takes the role of the giant and attracts the hatred of all Robin Hoods. Until than a shared development will be in my interest. 02-Sep-10 14:17What about reading a clipping of large ECWs over a slow (let's say 10MB ethernet) connection vs.

JPEG2000 - a common situation for a team working with a file server. Are JPEG2000 equivalent to ECWs in this situation?Don't know. A quick reading of the standard would indicate it is.ECWs use a lossy compression, yes. But the result often 'looks better' than the original because of a better contrast and the loss of unimportant details.

Is this the same for JPEG2000?Also don't know. Both ECW and JPEG2000 are wavelet based using similar ideas so I would be surprised if not. You could always alter contrast or resample the image to lose details if that's what you want.Manifold tells me 'Can't create Component'. Is there a difference in size restriction?Not to my knowledge. I'll ask around.Does the speed of manifold 9 with uncompressed or compressed images require a CUDA capable grafic card which is not present in many laptops?Not for display, panning, zooming, etc. 02-Sep-10 22:20What about reading a clipping of large ECWs over a slow (let's say 10MB ethernet) connection vs. JPEG2000 - a common situation for a team working with a file server.

Are JPEG2000 equivalent to ECWs in this situation?Yes.ECWs use a lossy compression, yes. But the result often 'looks better' than the original because of a better contrast and the loss of unimportant details. Is this the same for JPEG2000?Yes.

There are differences in implementation, but the main idea behind the formats is the same.I can't test because when I export my 0 pixel ECW to JEPG2000 I get the same file size but I can't link this file. Manifold tells me 'Can't create Component'. Is there a difference in size restriction?There is no difference in size restriction. You should be able to export and import / link images of unlimited size (there are technical limits, but nothing artificial like '500 MB max, until you upgrade to a higher-level version'), regardless of whether they are ECW or JPEG2000.I need projection aware images and I read in manifold help that JEPG2000 'should not be treated as a projection-aware format'. Has this changed?Not yet, but will change sooner or later.Mike answered the question on CUDA.

03-Sep-10 05:44I need projection aware images and I read in manifold help that JEPG2000 'should not be treated as a projection-aware format'. Has this changed?Not yet, but will change sooner or later.If this is work in progress I'd be VERY interested that it's done good and someone with a deep knowledge about projections and efficient programming is involved. Please manifold spend some of the precious engineering slots to serve the open source community in my best interest. I don't go back to worldfiles voluntarily. 03-Sep-10 07:04We are talking about deciphering the meaning of a coordinate system written by someone else, and about encoding a coordinate system so that others can understand what it is.The standard belongs to OpenGIS.The name of the standard document is 'GML in JPEG2000 for Geographic Imagery Encoding Specification'.(Think about what you just heard.)The exact wording in the standard is (section 6.7):Coverage geometries and the geometric properties of GML features and annotations include coordinates which are interpreted within the context of a coordinate reference system (CRS). According to the rules of GML, the coordinate reference system is specified via URI. This URI may identify the CRS by reference to an authority and an authority maintained code.

Alternatively, these URI may identify the physical location of a CRS definition.In those cases where an actual CRS definition is required, GML provides a grammar for encoding such coordinate reference systems. The coordinate reference system definitions encoded in GML can then be packaged with the JPEG 2000 data (as for features etc.) and referenced from the coverage description, or features, or can exist externally. This enables both network-centric and standalone implementations of GML in JPEG 2000 to be deployed.Some coordinate reference systems may require use of a GML coordinate reference system application schema. Mechanisms for referencing and/or transporting GML application schemas are discussed in Clause 8.Emphasis mine.Quoting a linked standard:The set of authorities recognised for the purposes of the OGC URN scheme is currently specified normatively in Table 1 in this document. In future it is expected that this mechanism will be replaced by a dynamic registry.Emphasis mine.There will be issues. 03-Sep-10 11:46But then there seems to be room for a demonstrative and open solution picking up existing concepts to take over the game.Here it is: JPEX (tm) consists of a standard JPEG2000 file packaged with a Manifold-written XML into a single.zip file. The open solution JPEX standard requires a zip file to assure that the JPEG2000 and the XML are kept together.

An XML file by itself or a JPEG2000 file by itself do not conform to the JPEX standard. Any modern OS can read a zip archive like an operating system folder to see either of the two sub-files that are in a JPEX. It is trademarked so no one can weaken the standard by claiming something is a JPEX when it is not.The structure of a Manifold-written XML is openly documented in. All aspects of every coordinate system listed are unambiguously available and discoverable. Anybody can use it. Anybody can write conforming XML files to match the JPEG2000. Using the XML totally eliminates all projection confusion issues and assures perfect import of images.The problem is not technology.

OGC participants know how to create effective formats. Their objective in OGC is to assure that no effective format emerges to threaten their proprietary interests.ESRI, for example, will not accept JPEX because it uses names for projections that Manifold happens to use. That would threaten ESRI's commercial interests.Note that JPEG2000 is not really an open standard because it is subject to significant legal claims and controls. It only appears to be open.

Suppose Manifold wanted to lead by example and to provide open source libraries for a JPEG2010 that consisted of JPEG2000 with embedded projection info without needing an accessory XML with GPGPU parallelization to provide an extra incentive to use it. That would not be possible because of the legal controls on JPEG2000. Manifold would have to spend more time than required to write that for the politics and legal work required to do that. 03-Sep-10 15:58Jpex as stated above would be a convenience for Manifold users, so they could write projected JPEG2000 and never worry about losing projection info - no way to lose the embedded XML. But because all components (JPEG2000, the XML, and zipfiles) are open it is also an example of an 'open standard' that exists today and is totally debugged.Could a different system be created, such as an XML variation that used EPSG codes? But that variation does not exist today.

It would have to be created and then debugged through extensive real-world use, where many unexpected combinations of coordinate system parameters are encountered. 04-Sep-10 09:03For an isolated Manifold community it seems perfect as it is but I doubt many of us live there. EPSG codes are in use.They are in use but by a surprisingly isolated community, much more isolated than Manifold.

Packages that use EPSG expose the actual process of dealing with EPSG to very few people, typically the administrator of a spatial DBMS or the creator of a web server application. EPSG codes are not usually encountered by many GIS users on the desktop. EPSG code users tend to be experts, so EPSG use has had little exposure to debugging by inexpert consumers.In contrast, virtually the entire commercial GIS community uses other things. 'World' files and PRJ are not EPSG, for example. Virtually none of the GIS data sets that may be downloaded from the world's inventory of online data sets are defined by EPSG codes. It is still mostly the usual mix of legacy formats that do not use EPSG, and inexpert consumers struggle with those.Of the commercial packages, because of the low cost of Manifold and the leveraging of Windows it is used by an extremely broad range of people with many different skill levels in many different types of GIS work throughout the world. That leads to very high variability of usage, which is good for debugging projections and how they are used.I agee with adamw that EPSG is a good thing.

It could be very useful if it were extended to the many projections encountered in the wild and used by Manifold. Manifold could propose additional codes to cover all Manifold projections but proposing them and getting them added is a nontrivial effort.It's tempting to add EPSG when it is available for a given projection. But that results in a less appealing standard if it works for some people but not for others.One solution may be that if EPSG cannot be extended to Manifold, that Manifold might limit exports to EPSG. Manifold could retain the ability to read and to work with all projections but would export only that subset within EPSG, with conversion on the fly proposed during export if a projection does not fall within EPSG. Manifold has considered such things as a way to promote EPSG and to sync closely with spatial DBMS that uses EPSG, but it is a radical notion that can have many unintended consequences.

Like anything, priorities expressed by users play an important role in whether such notions get traction. 04-Sep-10 14:29No objection!! I don't want you to enhance the EPSG system so that it can substitute Manifolds system. I only thought of an additional optional 31467 tag or an alternative flavor of a 'EPSG:31467' tag. Adding projections known to Manifold but not to EPSG is a job for the community primarily using EPSG. That means we would stay with the definition that there may be an identifier of authority and code.Manifold should be able to translate the complete intersection of its projections with that of the EPSG system because of it's openness to spatial DBMSs. We'r not there now.

Some of them like the example code are not recognized on export to PostGIS. But a complete set of the intersection of manifold and EPSG projections would be a good base for JPEX images.Don't get me wrong. I think it's correct that Manifold uses all the parameters of the projection as given by the projection.xml. It could only be a fallback mode to use a standard parameterset for a code if parameters are missing or a different precision of parameters. But a user of PostGIS only could concider it adequate and handy to have only an EPSG:code pair.Manifold could accept ESRI and GML names in system and date tags in addition to it's own names. It must have a lookup table for import and export of.prj and.gsr files already.

That's the maximum of 'uniform' in URI we can get.-The bundled but editable projection.xml file in JPEX is a very good idea. Much better than parameters hidden in an ECW file header. I don't need more projection awareness to switch to JPEG2000. 04-Sep-10 14:45Manifold should be able to translate the complete intersection of its projections with that of the EPSG system because of it's openness to spatial DBMSs. We'r not there now.I agree. It is a good goal.The bundled but editable projection.xml file in JPEX is a very good idea. Much better than parameters hidden in an ECW file header.I agree too.

Unfortunately, the big problem with JPEX as proposed is that accessing a zip archive is not free of computational cost, as has been pointed out to me by wiser engineers. The cost is not significant when writing, because creating a JPEG2000 already has a big computational cost.

But the cost of reading a JPEG2000 is very small (so they can display fast) and in that case the cost of decompressing a zip for random access reading of the JPEG2000 is significant. It can decrease the reading speed as compared to a straight JPEG2000 by.5 or.2 of the original speed.The only way around that while still guaranteeing that projection information travels with the JPEG2000 is what you and I don't like: putting tags inside the JPEG2000 that capture the same information as in the XML file.

One of those could be an EPSG tag too.These can be done so that any application that reads the JPEG2000 that doesn't understand the tags is not troubled by them. But it still puts the tags inside where they are not human readable the way an XML is. It could be that a simple open source applet could be posted that would report those tags in human readable form for non-JPEX aware applications.

08-Sep-10 07:04Hey that's great, thanks. I'm glad I posted it, very dim on this stuff. I'm keen to see the outcomes from the OSGeo developments.Adam I'm interested that you see the most significant problem in EPSG as being lack of coverage of Manifold's projections. I had a conversation recently about how EPSG is near perfect in terms of relational organization, and that it could have been extended in every direction for other forms of projections (such as time - my friend's favourite bugbear), but it is too locked down for that sort of generalization. (I can't recall exactly the details, but I think that was the thrust of the regretful complaint).

Do you see that Manifold's system could be developed to the point that it is published as a standard like EPSG is, and/or generalized to other spaces and dimensions?https://github.com/mdsumner. 08-Sep-10 07:36Actually (despite 'standard' being what I said) what I really am interested in is - an open box tool as a Manifold feature, with relational-level control over the various aspects and levels similar to that in EPSG, with all the added benefits. There are some limitations in the control one can have over the interpretation of different forms of projection metadata coming in to Manifold. Do you think the EPSG database design is a useful one, aside from its limitation in features?https://github.com/mdsumner. 08-Sep-10 13:20Do you see that Manifold's system could be developed to the point that it is published as a standard like EPSG is, and/or generalized to other spaces and dimensions?Almost anything is possible. The key question is what is prioritized ahead by users. Is the above something you would want?

Jpeg 2000 Dvr Support

If so, send in a suggestion:Manifold has been very reluctant to introduce new standards when there are perfectly good standards that could be used. EPSG is such a candidate.

Manifold lobbied Microsoft hard to consider EPSG for SQL Server spatial, for example, back when it was still Katmai. 03-Sep-10 06:04You should be able to export and import / link images of unlimited sizeBTW I solved the issue of 'Can't create Component' linking JEPG2000. This applies to files exported from a compressed image. Manifold allows this, shows no dialog to choose compression and copies the file with the new name. If I import an ECW, convert it to RGB(not a) and export to j2k with the same 10% compression rate that whas used creating the ECW with manifold the j2k file is 156% of the size of the ECW but links well and displays fast. 02-Sep-10 15:06Most of my GIS related business is with large organizations, i.e.

Municipal governments 5M or federal/provincial organizations and big utilities and telecoms. Although I've recommended adoption of JPEG2000 in the more progressive organizations, I rarely see it used in production anywhere.

Most imagery is either in TIFF or MrSID and more recently ECW. With the challenge of linking TB sized libraries of TIFF files or using proprietary SIDs in Manifold, it is my hope that at least ECW is fully supported.I gave up writing large mosaicked ECW files (i.e. 2GB) in Manifold, especially when I needed to transform images from MrSID, which necessitates exploding to TIFF before converting to ECW and that can be a brutally slow operation.

It also requires significant storage for temporary files (especially for those large tiles numbering in the thousands each greater then 100MB). This is where Global Mapper shines, and it has always been my hope that Manifold can provide similar capability, especially considering the similar price points of that products. Their one step process from MrSID to ECW is also very elegant.As others have stated, ECW seems to be superior to JPEG2000 from a performance standpoint and it has been adopted in many organizations, especially those that have transitioned from MrSID and have pushed their TIFF sources to the archives.

I therefore think it would be a mistake to reduce Manifold's stake in this format. 02-Sep-10 15:20Q1 For my part I would be happy to only read ECW and to read write JPEG2000. Currently we tend to use ECW by default in other systems as in my experience it seems to be more widely supported and generally more performant than JPEG2000 implementations.Q2 No for the reasons Gustavo mentions.Q3 For me this would be desirable though not essential. In short, I would find it a nice to have but I have already bought third party products (Global Mapper) to expedite this process compared to Manifold 8. As dgallen mentions, I too have always hoped that Manifold would at least be able to match or better the performance of Global Mapper in the compression/decompression arena.

Presumably GM isn’t parallelised though perhaps makes some other tradeoffs to achieve its performance?Landsystems Ltd. Know your land www.landsystems.co.nz. 02-Sep-10 16:15Presumably GM doesn’t isn’t parallelised though perhaps makes some other tradeoffs to achieve its performance?Manipulating big rasters is primarily about data access.GM has a data structure good for rasters but not good for other data.

This is not difficult to do. What is very difficult is to create a data access layer that is orthogonal and can work with different data types simultaneously. For example, working with big databases and big vectors as well as big rasters. There are no database constructs, queries, etc. In global mapper, and no significant vector GIS facilities as expected with true vector GIS products like MapInfo, ArcMap, Manifold.A second task is creating a data access layer that is not linear. It is not difficult to pull rasters off in linear sequence from one file on disk and display them onscreen or put them into another file on disk. It is very difficult to provide ordered storage so that many different threads can asynchronously pull what they need when they need it, do computation, and then put the results together.

This is a requirement for multiuser editing and enterprise applications or IMS applications as well as parallel computation.A third task is computational efficiency. It is not difficult to create a data access layer optimized for the display of rasters. It is much more difficult to create a data access layer that is good for significant computation on the data contained in layers.The tradeoffs GM has made are primarily in the above three areas: 1. They have a non-orthogonal data access pipeline that is good for rasters and useless for other things, like big tables, big drawings or DBMS. They've implemented a simple, linear data access system that is not good for enterprise or other complex settings and 3. They do near-zero computation.An example of all three limitations at once would be to ask for a spatial SQL query from GM that combined data from rasters, vectors and tables to synthesize new objects and to perform a sophisticated computation on them.

Can't be done. There is no capability to do elementary GIS things involving vectors that are easily performed by GIS packages like ArcView or MapInfo. There is no simultaneous display of multiple different data types in a map with layers being re-projected on the fly. It is very difficult for a raster-oriented data access model to add such capabilities.Most people regard the signature benefit of GIS is the ability to combine database with objects and other data, including raster images or surfaces, but primarily vectors, and to do analytics or sophisticated manipulation.

If you don't have that you are not a GIS. No company has yet introduced a product that does GIS and also does a good job competing with the raster companies like ERDAS (or on a smaller scale GM) in raster work.

That's why the GIS market has segments like GIS and Rasters. In another area there is also segmentation into GIS and CAD.Manifold does rasters but has not focussed on that to the degree required to replace dedicated raster companies when rasters are large. 64-bit Manifold is more than competitive enough in rasters against other GIS companies but not against raster companies like ERDAS. I expect that to change as the new products come out and users start taking advantage of their ability to handle large rasters very well. 02-Sep-10 16:32Yes thanks for asking Mike.I'm pretty sure the top item on the Manifold GIS wishlist is getting Manifold 9 stable for release, and number 2 is getting it into users' eager hands.

No new features could come anywhere near those priorities.But for a future version, beyond 9. Should Manifold parallelize JPEG2000 (if this takes away from other Manifold wishlist items) or is current state of the art good enough if this format is used only for interchange?Yes please, eventually, because it fits so well with export to PDF (regular or Geospatial). JPEG2000 inside PDF is a very fast and convenient way to distribute data to clients for reference and approval (GIS-literate and GIS-agnostic users alike), and its fine-grained control over compression and quality (including the option of lossless compression) make it the format of choice (in my opinion) for PDF imagery.(There is no support for ECW inside PDF, and probably never will be, and as ar as I know ECW does not do lossless compression.)PDF also looks like the shortest line between Manifold content and an iPad (along with similar devices), for the time being anyway. This is likely to become an important platform for all of us, if it's not already.2.

Should Manifold provide open source code for read/write JPEG2000 if this takes away from other Manifold wishlist items?I'm not sure whether you mean a parallelized version or a standard version. And I don't know what obligations there are on JPEG2000 developers. But assuming the most interesting case, i.e.

That Manifold had a parallelized JPEG2000 encoder, and was under no obligation to publish its source code, I'd say no, or rather not without a decent quid pro quo. For example it might be used to swing some corresponding openness out of the likes of Apple or Adobe. Otherwise why not offer to license it, likewise to Adobe (or Apple).1. Is it OK for Manifold to continue reading ECW but to write only JPEG2000?I suppose so, but I'd rather see Manifold support the openness of ECW for however long it lasts, while making it clear that export support will probably cease should the format become closed. That would help to encourage the owners of ECW to maintain its openness, which I'm sure makes life easier for smaller developers like Mike Childs (Global Mapper) and Avenza (Geographic Imager) as well as open source developers.More generally, I hope Manifold will continue to invest in maintaining a significant lead over ESRI in the 'openness' game, which besides the sharing of code is about facilitating data interchange, refactoring, and common standards.

If it's not about users, clients and their data, it's a sideshow. Manifold has always taken this attitude while ESRI seems to prefer sideshows (and golf, and lunch). An investment of 'wish list' time in JPEG2000 could be justified in that way, largely because of the link to PDF, but there might be better candidates. For example, I wonder whether Manifold plans to develop an SDK to work with its new storage model, or what licencing arrangements it would apply if it did. 02-Sep-10 17:46Hey Mike.Good questions all. My 2 cents:. like others have stated, I too have many clients with ECW formatted imagery, so the ability to read this is indeed a requirement.

Ecw Jpeg 2000 Compressor Car Parts

Overall I would be fine with the ability to read ECW/JPEG2k and only write JPEG2K. I'd rather see the wish list items get worked on.

If this is important to folks - they should 'wish' it and get it on the list. Again - would rather see wish list items worked on; if this is important people can 'wish' it and move it up the priority list that way.Thanks for asking! jaburn. 10-Jun-11 10:32This seems to be complicated by the large number of extensions used for JPEG 2000. If my reading of wikipedia is correct that (only?).jp2 or.jpg2 is the extension for the file format. This contains matadata like size of pixel and offset, may be projection in a userdefined parameter.

The worldfile extension should read.j2w but would not be neccessary ideally.The other extensions (.j2k,.jpf,.jpx) are used for the codestream, i.e. The image only without metadata.

This is where a worldfile would make sense but the worldfile wouldn't have a distinct extension but.jkw,.jfw or jxw.I can't test this with manifold only because manifold exports includes offsets and pixels size in metadata with all extensions, it acually only exports the true file format.jp2 but with the choosen extension and not the codestream. For reading and linking the existence of metadata and it's internal parameters of the file take precedence over a worldfile for all possible extensions. Check the data and don't guess from extension.

ECW

Makes sense given the babel in the wild.For the test of a worldfile we can only use a true codestream file created by some other software.