Search Results

Search found 42 results on 2 pages for 'bhargav bhat'.

Page 2/2 | < Previous Page | 1 2 

  • How do I measure distances in an image?

    - by Ram Bhat
    Let's say we have an image like so Let's say we've already used filters and an edge detection algorithm in this pic. Now my goal is to measure distances (NOT actual distances, distance can be in any arbitrary unit) . eg: How do I find the length of the hall? (until the window) Or the height of the bookshelves? How exactly do you place the "scale" and measure. I'm looking for ideas. However it would help if the answers were in terms of OpenCV.

    Read the article

  • Error in VC++ for code that looks perfectly good C++?

    - by Ram Bhat
    Hey guys. Check out this piece of sample code. #include "stdafx.h" #include<conio.h> #include<string.h> class person{ private char name[20]; private int age; public void setValues(char n[],int a) { strcpy(this->name,n); this->age=a; } public void display() { printf("\nName = %s",name); printf("\nAge = %d",age); } }; int _tmain(int argc, _TCHAR* argv[]) { person p; p.setValues("ram",20); p.display(); getch(); return 0; } I am getting the following errors : 1------ Build started: Project: first, Configuration: Debug Win32 ------ 1 first.cpp 1c:\documents and settings\dark wraith\my documents\visual studio 2010\projects\first\first\first.cpp(9): error C2144: syntax error : 'char' should be preceded by ':' 1c:\documents and settings\dark wraith\my documents\visual studio 2010\projects\first\first\first.cpp(10): error C2144: syntax error : 'int' should be preceded by ':' 1c:\documents and settings\dark wraith\my documents\visual studio 2010\projects\first\first\first.cpp(12): error C2144: syntax error : 'void' should be preceded by ':' 1c:\documents and settings\dark wraith\my documents\visual studio 2010\projects\first\first\first.cpp(17): error C2144: syntax error : 'void' should be preceded by ':' ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

    Read the article

  • vim regex for replacing spaces within quotes

    - by vikram-bhat
    I have text in the follwing format: ERR_OUT_OF_MEM, "ERR OUT OF MEM" ERR_SOMETHING_BAD, "ERR SOMETHING BAD" I want to replace all spaces in the text which are within quotes with underscores: ERR_OUT_OF_MEM, "ERR_OUT_OF_MEM" ERR_SOMETHING_BAD, "ERR_SOMETHING_BAD" The best regex I could come up with is: \("\w\+\)\@<= (there's a space at the end of that) but this only finds the first space in each quoted string, and I would need to repeat this multiple times to get the desired effect. Any way to do it in one shot? Thanks!

    Read the article

  • Need to Post json data using jQuery.ajax

    - by Anil Bhat
    I have a json of the following format which I need to send in the Ajax request through POST method: { “gbus”: [ { "code": "*" } ], “regions”: [ { "code": "*" } ], “offices”: [ { "code": "*" } ], “contracttypes”: [ { "code": "*" } ], “jobnumbers”: [ { "code": "*" } ], “disciplines”: [ { "code": "*" } ] } Its not working for me, giving 500 error always when I try to submit it. Please suggest if you have any idea.

    Read the article

  • why no += operator for vectors in stl

    - by Akshay Bhat
    I am curious? What high fundu logic goes behind not implementing: result+=vector1; where both result and vector1 are stl vectors. Note: i know how to implement that bit, but i need to know what logic, the sages who designed STL were using when they chose not to implement this feature?

    Read the article

  • How would you find the height of objects given an image?

    - by Ram Bhat
    Heyguys.. This isn't exactly a programming question exactly. I just want to know what your approach would be to a common problem in Digital image processing. Lets say you have an image of a a few trees in say jpg format. How would you go about finding the heights of each of these trees. The photo is the only input you have. I want to know the approaches you have not code. So it doesnt matter if your answers are vague, or non DIP-ish.

    Read the article

  • Google I/O 2012 - Monetizing Digital Goods with Google Wallet

    Google I/O 2012 - Monetizing Digital Goods with Google Wallet Joel Leitch, Dan Zink, Pali Bhat Whether you're a game developer selling virtual goods or currencies, or a media developer selling news content, videos, music or any other premium digital media, having an simple way to process payments from your customers is important. In this session, we will walk through an explanation of Google Wallet for digital goods, the new features, and the improved pricing model for developers. In addition, Kabam will share their experience with Google Wallet and best practices for integration. For all I/O 2012 sessions, go to developers.google.com From: GoogleDevelopers Views: 307 13 ratings Time: 44:31 More in Science & Technology

    Read the article

  • Security in Software

    The term security has many meanings based on the context and perspective in which it is used. Security from the perspective of software/system development is the continuous process of maintaining confidentiality, integrity, and availability of a system, sub-system, and system data. This definition at a very high level can be restated as the following: Computer security is a continuous process dealing with confidentiality, integrity, and availability on multiple layers of a system. Key Aspects of Software Security Integrity Confidentiality Availability Integrity within a system is the concept of ensuring only authorized users can only manipulate information through authorized methods and procedures. An example of this can be seen in a simple lead management application.  If the business decided to allow each sales member to only update their own leads in the system and sales managers can update all leads in the system then an integrity violation would occur if a sales member attempted to update someone else’s leads. An integrity violation occurs when a team member attempts to update someone else’s lead because it was not entered by the sales member.  This violates the business rule that leads can only be update by the originating sales member. Confidentiality within a system is the concept of preventing unauthorized access to specific information or tools.  In a perfect world the knowledge of the existence of confidential information/tools would be unknown to all those who do not have access. When this this concept is applied within the context of an application only the authorized information/tools will be available. If we look at the sales lead management system again, leads can only be updated by originating sales members. If we look at this rule then we can say that all sales leads are confidential between the system and the sales person who entered the lead in to the system. The other sales team members would not need to know about the leads let alone need to access it. Availability within a system is the concept of authorized users being able to access the system. A real world example can be seen again from the lead management system. If that system was hosted on a web server then IP restriction can be put in place to limit access to the system based on the requesting IP address. If in this example all of the sales members where accessing the system from the 192.168.1.23 IP address then removing access from all other IPs would be need to ensure that improper access to the system is prevented while approved users can access the system from an authorized location. In essence if the requesting user is not coming from an authorized IP address then the system will appear unavailable to them. This is one way of controlling where a system is accessed. Through the years several design principles have been identified as being beneficial when integrating security aspects into a system. These principles in various combinations allow for a system to achieve the previously defined aspects of security based on generic architectural models. Security Design Principles Least Privilege Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation Privilege Least Common Mechanism Psychological Acceptability Defense in Depth Least Privilege Design PrincipleThe Least Privilege design principle requires a minimalistic approach to granting user access rights to specific information and tools. Additionally, access rights should be time based as to limit resources access bound to the time needed to complete necessary tasks. The implications of granting access beyond this scope will allow for unnecessary access and the potential for data to be updated out of the approved context. The assigning of access rights will limit system damaging attacks from users whether they are intentional or not. This principle attempts to limit data changes and prevents potential damage from occurring by accident or error by reducing the amount of potential interactions with a resource. Fail-Safe Defaults Design PrincipleThe Fail-Safe Defaults design principle pertains to allowing access to resources based on granted access over access exclusion. This principle is a methodology for allowing resources to be accessed only if explicit access is granted to a user. By default users do not have access to any resources until access has been granted. This approach prevents unauthorized users from gaining access to resource until access is given. Economy of Mechanism Design PrincipleThe Economy of mechanism design principle requires that systems should be designed as simple and small as possible. Design and implementation errors result in unauthorized access to resources that would not be noticed during normal use. Complete Mediation Design PrincipleThe Complete Mediation design principle states that every access to every resource must be validated for authorization. Open Design Design PrincipleThe Open Design Design Principle is a concept that the security of a system and its algorithms should not be dependent on secrecy of its design or implementation Separation Privilege Design PrincipleThe separation privilege design principle requires that all resource approved resource access attempts be granted based on more than a single condition. For example a user should be validated for active status and has access to the specific resource. Least Common Mechanism Design PrincipleThe Least Common Mechanism design principle declares that mechanisms used to access resources should not be shared. Psychological Acceptability Design PrincipleThe Psychological Acceptability design principle refers to security mechanisms not make resources more difficult to access than if the security mechanisms were not present Defense in Depth Design PrincipleThe Defense in Depth design principle is a concept of layering resource access authorization verification in a system reduces the chance of a successful attack. This layered approach to resource authorization requires unauthorized users to circumvent each authorization attempt to gain access to a resource. When designing a system that requires meeting a security quality attribute architects need consider the scope of security needs and the minimum required security qualities. Not every system will need to use all of the basic security design principles but will use one or more in combination based on a company’s and architect’s threshold for system security because the existence of security in an application adds an additional layer to the overall system and can affect performance. That is why the definition of minimum security acceptably is need when a system is design because this quality attributes needs to be factored in with the other system quality attributes so that the system in question adheres to all qualities based on the priorities of the qualities. Resources: Barnum, Sean. Gegick, Michael. (2005). Least Privilege. Retrieved on August 28, 2011 from https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/principles/351-BSI.html Saltzer, Jerry. (2011). BASIC PRINCIPLES OF INFORMATION PROTECTION. Retrieved on August 28, 2011 from  http://web.mit.edu/Saltzer/www/publications/protection/Basic.html Barnum, Sean. Gegick, Michael. (2005). Defense in Depth. Retrieved on August 28, 2011 from  https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/principles/347-BSI.html Bertino, Elisa. (2005). Design Principles for Security. Retrieved on August 28, 2011 from  http://homes.cerias.purdue.edu/~bhargav/cs526/security-9.pdf

    Read the article

< Previous Page | 1 2