From matt.brown at kitware.com Fri Jan 5 13:41:13 2018 From: matt.brown at kitware.com (Matt Brown) Date: Fri, 5 Jan 2018 13:41:13 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization Message-ID: A bit of a semantics question, but I'd like to make an ocv arrow that does histogram equalization and another that stretches contrast in an image. The vital *image_filter* prototype fits in that an image goes in and one comes out, with the same resolution as the input as is typical of a filter. However, semantically, I'm not sure histogram equalization is really a filter operation. Does it make sense to: 1. Just call it a filter and be done with. 2. Create an effective duplicate of the filter algorithm and call it something more in line with contrast enhancement. 3. plan to rename filter_image to something more generic like process_image. Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Fri Jan 5 13:54:21 2018 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Fri, 5 Jan 2018 13:54:21 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: References: Message-ID: If we lump all image-in, image-out implementations under one algorithm (e.g. filter_image), they will all appear in one list and it will be hard to find what you are looking for. In this case, if there will be multiple implementations for contrast enhancement, then I think it makes sense to have a base algorithm for contrast_enhancement even though the code looks the same as filter_image. This approach also constrains which algorithm can be configured if it is limited to contrast_enhancement, rather than using the broader category of filter_image. Comments welcome. On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown wrote: > A bit of a semantics question, but I'd like to make an ocv arrow that does > histogram equalization and another that stretches contrast in an image. The > vital *image_filter* prototype fits in that an image goes in and one > comes out, with the same resolution as the input as is typical of a filter. > However, semantically, I'm not sure histogram equalization is really a > filter operation. Does it make sense to: > > 1. Just call it a filter and be done with. > 2. Create an effective duplicate of the filter algorithm and call it > something more in line with contrast enhancement. > 3. plan to rename filter_image to something more generic like > process_image. > > Thanks, > Matt > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users > > -- *Linus Sherrill - *Staff R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065-8662 E: linus.sherrill at kitware.com P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Fri Jan 5 14:04:15 2018 From: matt.brown at kitware.com (Matt Brown) Date: Fri, 5 Jan 2018 14:04:15 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: References: Message-ID: I think that makes sense. When naming the arrow, should there be an attempt to indicate the vital algorithm within the name? For example, for the image_filter algorithm, I called my arrows filter_gaussian_blur and filter_blur, the later half reflecting the primary OCV function being called. On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill wrote: > If we lump all image-in, image-out implementations under one algorithm > (e.g. filter_image), they will all appear in one list and it will be hard > to find what you are looking for. In this case, if there will be multiple > implementations for contrast enhancement, then I think it makes sense to > have a base algorithm for contrast_enhancement even though the code looks > the same as filter_image. This approach also constrains which algorithm can > be configured if it is limited to contrast_enhancement, rather than using > the broader category of filter_image. > > Comments welcome. > > > On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown wrote: > >> A bit of a semantics question, but I'd like to make an ocv arrow that >> does histogram equalization and another that stretches contrast in an >> image. The vital *image_filter* prototype fits in that an image goes in >> and one comes out, with the same resolution as the input as is typical of a >> filter. However, semantically, I'm not sure histogram equalization is >> really a filter operation. Does it make sense to: >> >> 1. Just call it a filter and be done with. >> 2. Create an effective duplicate of the filter algorithm and call it >> something more in line with contrast enhancement. >> 3. plan to rename filter_image to something more generic like >> process_image. >> >> Thanks, >> Matt >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/kwiver-users >> >> > > > -- > *Linus Sherrill - *Staff R&D Engineer > Kitware, Inc. > 28 Corporate Drive > > Clifton Park, NY 12065 > > -8662 > E: linus.sherrill at kitware.com > P: 518.881.4400 <(518)%20881-4400> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Fri Jan 5 14:54:48 2018 From: matt.leotta at kitware.com (Matthew Leotta) Date: Fri, 5 Jan 2018 14:54:48 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: References: Message-ID: <7F74FF27-E0AE-4A04-BE8C-1C0D9FEAB250@kitware.com> Matt, In this case I would say image equalization and contrast stretching does match the semantics of ?image_filter?. Image filter should be any sort of image manipulation routine that returns a variant of the image that is enhanced/modified in some way. It is not meant to be a strict definition of ?filter? meaning only operations that can be implemented as a convolution or some other spatially local operation. Think filter in the sense of the filters menu in the GIMP image editing program. That said, there could be other cases where the input and output types match, but the semantics are different. In that case, I agree with Linus that you should have different abstract algorithms in vital. Imagine an algorithm that take an image and uses it as a query to find and return another image which is most similar in a database. That could also have image in and image out, but I would argue that is not a filter. Also keep in mind that not every function or algorithm needs to be an abstract algorithm in Vital. The abstract algorithms should represent functional components that you can combine into an application, but where you would reasonably expect to swap out different algorithms for each abstract algorithm. Algorithms best suited for vital/algo are components where you might expect someone to write a paper or a new software project on a better/faster way to do X, or where there are already various competing software packages providing a way to do X. There may be a point in the future where we have so many image filters that we need to organize them better or create subsets of image filters with more specific applications (like blurring). We are not at that point yet. ?Matt > On Jan 5, 2018, at 2:04 PM, Matt Brown wrote: > > I think that makes sense. When naming the arrow, should there be an attempt to indicate the vital algorithm within the name? For example, for the image_filter algorithm, I called my arrows filter_gaussian_blur and filter_blur, the later half reflecting the primary OCV function being called. > > On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill > wrote: > If we lump all image-in, image-out implementations under one algorithm (e.g. filter_image), they will all appear in one list and it will be hard to find what you are looking for. In this case, if there will be multiple implementations for contrast enhancement, then I think it makes sense to have a base algorithm for contrast_enhancement even though the code looks the same as filter_image. This approach also constrains which algorithm can be configured if it is limited to contrast_enhancement, rather than using the broader category of filter_image. > > Comments welcome. > > > On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown > wrote: > A bit of a semantics question, but I'd like to make an ocv arrow that does histogram equalization and another that stretches contrast in an image. The vital image_filter prototype fits in that an image goes in and one comes out, with the same resolution as the input as is typical of a filter. However, semantically, I'm not sure histogram equalization is really a filter operation. Does it make sense to: > Just call it a filter and be done with. > Create an effective duplicate of the filter algorithm and call it something more in line with contrast enhancement. > plan to rename filter_image to something more generic like process_image. > Thanks, > Matt > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users > > > > > -- > Linus Sherrill - Staff R&D Engineer > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 -8662 > E: linus.sherrill at kitware.com > P: 518.881.4400 > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Fri Jan 5 15:22:28 2018 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Fri, 5 Jan 2018 15:22:28 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: <7F74FF27-E0AE-4A04-BE8C-1C0D9FEAB250@kitware.com> References: <7F74FF27-E0AE-4A04-BE8C-1C0D9FEAB250@kitware.com> Message-ID: With regard to naming implementations, I do not think you need to add the abstract algorithm name to the new algo name. It seems redundant. When listing the algorithms, the base algo name is listed in addition to the implementation name. On Fri, Jan 5, 2018 at 2:54 PM, Matthew Leotta wrote: > Matt, > > In this case I would say image equalization and contrast stretching does > match the semantics of ?image_filter?. Image filter should be any sort of > image manipulation routine that returns a variant of the image that is > enhanced/modified in some way. It is not meant to be a strict definition > of ?filter? meaning only operations that can be implemented as a > convolution or some other spatially local operation. Think filter in the > sense of the filters menu in the GIMP image editing program. > > That said, there could be other cases where the input and output types > match, but the semantics are different. In that case, I agree with Linus > that you should have different abstract algorithms in vital. Imagine an > algorithm that take an image and uses it as a query to find and return > another image which is most similar in a database. That could also have > image in and image out, but I would argue that is not a filter. > > Also keep in mind that not every function or algorithm needs to be an > abstract algorithm in Vital. The abstract algorithms should represent > functional components that you can combine into an application, but where > you would reasonably expect to swap out different algorithms for each > abstract algorithm. Algorithms best suited for vital/algo are components > where you might expect someone to write a paper or a new software project > on a better/faster way to do X, or where there are already various > competing software packages providing a way to do X. > > There may be a point in the future where we have so many image filters > that we need to organize them better or create subsets of image filters > with more specific applications (like blurring). We are not at that point > yet. > > ?Matt > > > On Jan 5, 2018, at 2:04 PM, Matt Brown wrote: > > I think that makes sense. When naming the arrow, should there be an > attempt to indicate the vital algorithm within the name? For example, for > the image_filter algorithm, I called my arrows filter_gaussian_blur and > filter_blur, the later half reflecting the primary OCV function being > called. > > On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill > wrote: > >> If we lump all image-in, image-out implementations under one algorithm >> (e.g. filter_image), they will all appear in one list and it will be hard >> to find what you are looking for. In this case, if there will be multiple >> implementations for contrast enhancement, then I think it makes sense to >> have a base algorithm for contrast_enhancement even though the code >> looks the same as filter_image. This approach also constrains which >> algorithm can be configured if it is limited to contrast_enhancement, >> rather than using the broader category of filter_image. >> >> Comments welcome. >> >> >> On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown >> wrote: >> >>> A bit of a semantics question, but I'd like to make an ocv arrow that >>> does histogram equalization and another that stretches contrast in an >>> image. The vital *image_filter* prototype fits in that an image goes in >>> and one comes out, with the same resolution as the input as is typical of a >>> filter. However, semantically, I'm not sure histogram equalization is >>> really a filter operation. Does it make sense to: >>> >>> 1. Just call it a filter and be done with. >>> 2. Create an effective duplicate of the filter algorithm and call it >>> something more in line with contrast enhancement. >>> 3. plan to rename filter_image to something more generic like >>> process_image. >>> >>> Thanks, >>> Matt >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> https://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >> >> >> -- >> *Linus Sherrill - *Staff R&D Engineer >> Kitware, Inc. >> 28 Corporate Drive >> >> Clifton Park, NY 12065 >> >> -8662 >> E: linus.sherrill at kitware.com >> P: 518.881.4400 <(518)%20881-4400> >> > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users > > > -- *Linus Sherrill - *Staff R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065-8662 E: linus.sherrill at kitware.com P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Fri Jan 5 15:46:21 2018 From: matt.leotta at kitware.com (Matthew Leotta) Date: Fri, 5 Jan 2018 15:46:21 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: References: <7F74FF27-E0AE-4A04-BE8C-1C0D9FEAB250@kitware.com> Message-ID: <5B9EC111-AA16-4AC4-915D-B04E76970258@kitware.com> I agree on that point when it comes to name of the algorithm (e.g. string name you pass when registering the algorithms). However, when it comes to naming the .cxx file and the class itself, it can be useful to incorporate the name of the algorithm to make them easier to find in a list of files. Sometimes we give the class in the arrow the same name as the vital algorithm, just in a different namespace, and the name passed to the plugin is the same name as the arrow. For example, ocv::estimate_homography is registered as ?ocv? and derived from vital::estimate_homography. This only works if you can reasonably expect there to be only one implementation of the algorithm provided by that arrow. If this is not the case, another naming scheme we have used is to append another descriptive name to each of these. For example, ocv::extract_descriptors_BRIEF is registered as ?ocv_BRIEF? and is derived from vital::extract_descriptors. There are other variations where ?BRIEF? is replaced by another name. ?Matt > On Jan 5, 2018, at 3:22 PM, Linus Sherrill wrote: > > With regard to naming implementations, I do not think you need to add the abstract algorithm name to the new algo name. It seems redundant. When listing the algorithms, the base algo name is listed in addition to the implementation name. > > On Fri, Jan 5, 2018 at 2:54 PM, Matthew Leotta > wrote: > Matt, > > In this case I would say image equalization and contrast stretching does match the semantics of ?image_filter?. Image filter should be any sort of image manipulation routine that returns a variant of the image that is enhanced/modified in some way. It is not meant to be a strict definition of ?filter? meaning only operations that can be implemented as a convolution or some other spatially local operation. Think filter in the sense of the filters menu in the GIMP image editing program. > > That said, there could be other cases where the input and output types match, but the semantics are different. In that case, I agree with Linus that you should have different abstract algorithms in vital. Imagine an algorithm that take an image and uses it as a query to find and return another image which is most similar in a database. That could also have image in and image out, but I would argue that is not a filter. > > Also keep in mind that not every function or algorithm needs to be an abstract algorithm in Vital. The abstract algorithms should represent functional components that you can combine into an application, but where you would reasonably expect to swap out different algorithms for each abstract algorithm. Algorithms best suited for vital/algo are components where you might expect someone to write a paper or a new software project on a better/faster way to do X, or where there are already various competing software packages providing a way to do X. > > There may be a point in the future where we have so many image filters that we need to organize them better or create subsets of image filters with more specific applications (like blurring). We are not at that point yet. > > ?Matt > > >> On Jan 5, 2018, at 2:04 PM, Matt Brown > wrote: >> >> I think that makes sense. When naming the arrow, should there be an attempt to indicate the vital algorithm within the name? For example, for the image_filter algorithm, I called my arrows filter_gaussian_blur and filter_blur, the later half reflecting the primary OCV function being called. >> >> On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill > wrote: >> If we lump all image-in, image-out implementations under one algorithm (e.g. filter_image), they will all appear in one list and it will be hard to find what you are looking for. In this case, if there will be multiple implementations for contrast enhancement, then I think it makes sense to have a base algorithm for contrast_enhancement even though the code looks the same as filter_image. This approach also constrains which algorithm can be configured if it is limited to contrast_enhancement, rather than using the broader category of filter_image. >> >> Comments welcome. >> >> >> On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown > wrote: >> A bit of a semantics question, but I'd like to make an ocv arrow that does histogram equalization and another that stretches contrast in an image. The vital image_filter prototype fits in that an image goes in and one comes out, with the same resolution as the input as is typical of a filter. However, semantically, I'm not sure histogram equalization is really a filter operation. Does it make sense to: >> Just call it a filter and be done with. >> Create an effective duplicate of the filter algorithm and call it something more in line with contrast enhancement. >> plan to rename filter_image to something more generic like process_image. >> Thanks, >> Matt >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/kwiver-users >> >> >> >> >> -- >> Linus Sherrill - Staff R&D Engineer >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 -8662 >> E: linus.sherrill at kitware.com >> P: 518.881.4400 >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/kwiver-users > > > > > -- > Linus Sherrill - Staff R&D Engineer > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065-8662 > E: linus.sherrill at kitware.com > P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Fri Jan 5 15:56:42 2018 From: matt.brown at kitware.com (Matt Brown) Date: Fri, 5 Jan 2018 15:56:42 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: <5B9EC111-AA16-4AC4-915D-B04E76970258@kitware.com> References: <7F74FF27-E0AE-4A04-BE8C-1C0D9FEAB250@kitware.com> <5B9EC111-AA16-4AC4-915D-B04E76970258@kitware.com> Message-ID: Thanks for the feedback. Would be nice to funnel this advice into a style guide at some point. On Fri, Jan 5, 2018 at 3:46 PM, Matthew Leotta wrote: > I agree on that point when it comes to name of the algorithm (e.g. string > name you pass when registering the algorithms). However, when it comes to > naming the .cxx file and the class itself, it can be useful to incorporate > the name of the algorithm to make them easier to find in a list of files. > Sometimes we give the class in the arrow the same name as the vital > algorithm, just in a different namespace, and the name passed to the plugin > is the same name as the arrow. For example, ocv::estimate_homography is > registered as ?ocv? and derived from vital::estimate_homography. This only > works if you can reasonably expect there to be only one implementation of > the algorithm provided by that arrow. If this is not the case, another > naming scheme we have used is to append another descriptive name to each of > these. For example, ocv::extract_descriptors_BRIEF is registered as > ?ocv_BRIEF? and is derived from vital::extract_descriptors. There are > other variations where ?BRIEF? is replaced by another name. > > ?Matt > > > On Jan 5, 2018, at 3:22 PM, Linus Sherrill > wrote: > > With regard to naming implementations, I do not think you need to add the > abstract algorithm name to the new algo name. It seems redundant. When > listing the algorithms, the base algo name is listed in addition to the > implementation name. > > On Fri, Jan 5, 2018 at 2:54 PM, Matthew Leotta > wrote: > >> Matt, >> >> In this case I would say image equalization and contrast stretching does >> match the semantics of ?image_filter?. Image filter should be any sort of >> image manipulation routine that returns a variant of the image that is >> enhanced/modified in some way. It is not meant to be a strict definition >> of ?filter? meaning only operations that can be implemented as a >> convolution or some other spatially local operation. Think filter in the >> sense of the filters menu in the GIMP image editing program. >> >> That said, there could be other cases where the input and output types >> match, but the semantics are different. In that case, I agree with Linus >> that you should have different abstract algorithms in vital. Imagine an >> algorithm that take an image and uses it as a query to find and return >> another image which is most similar in a database. That could also have >> image in and image out, but I would argue that is not a filter. >> >> Also keep in mind that not every function or algorithm needs to be an >> abstract algorithm in Vital. The abstract algorithms should represent >> functional components that you can combine into an application, but where >> you would reasonably expect to swap out different algorithms for each >> abstract algorithm. Algorithms best suited for vital/algo are components >> where you might expect someone to write a paper or a new software project >> on a better/faster way to do X, or where there are already various >> competing software packages providing a way to do X. >> >> There may be a point in the future where we have so many image filters >> that we need to organize them better or create subsets of image filters >> with more specific applications (like blurring). We are not at that point >> yet. >> >> ?Matt >> >> >> On Jan 5, 2018, at 2:04 PM, Matt Brown wrote: >> >> I think that makes sense. When naming the arrow, should there be an >> attempt to indicate the vital algorithm within the name? For example, for >> the image_filter algorithm, I called my arrows filter_gaussian_blur and >> filter_blur, the later half reflecting the primary OCV function being >> called. >> >> On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill < >> linus.sherrill at kitware.com> wrote: >> >>> If we lump all image-in, image-out implementations under one algorithm >>> (e.g. filter_image), they will all appear in one list and it will be hard >>> to find what you are looking for. In this case, if there will be multiple >>> implementations for contrast enhancement, then I think it makes sense >>> to have a base algorithm for contrast_enhancement even though the code >>> looks the same as filter_image. This approach also constrains which >>> algorithm can be configured if it is limited to contrast_enhancement, >>> rather than using the broader category of filter_image. >>> >>> Comments welcome. >>> >>> >>> On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown >>> wrote: >>> >>>> A bit of a semantics question, but I'd like to make an ocv arrow that >>>> does histogram equalization and another that stretches contrast in an >>>> image. The vital *image_filter* prototype fits in that an image goes >>>> in and one comes out, with the same resolution as the input as is typical >>>> of a filter. However, semantically, I'm not sure histogram equalization is >>>> really a filter operation. Does it make sense to: >>>> >>>> 1. Just call it a filter and be done with. >>>> 2. Create an effective duplicate of the filter algorithm and call >>>> it something more in line with contrast enhancement. >>>> 3. plan to rename filter_image to something more generic like >>>> process_image. >>>> >>>> Thanks, >>>> Matt >>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> https://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>> >>> >>> -- >>> *Linus Sherrill - *Staff R&D Engineer >>> Kitware, Inc. >>> 28 Corporate Drive >>> >>> Clifton Park, NY 12065 >>> >>> -8662 >>> E: linus.sherrill at kitware.com >>> P: 518.881.4400 <(518)%20881-4400> >>> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/kwiver-users >> >> >> > > > -- > *Linus Sherrill - *Staff R&D Engineer > Kitware, Inc. > 28 Corporate Drive > > Clifton Park, NY 12065 > > -8662 > E: linus.sherrill at kitware.com > P: 518.881.4400 <(518)%20881-4400> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Fri Jan 5 16:04:38 2018 From: matt.leotta at kitware.com (Matthew Leotta) Date: Fri, 5 Jan 2018 16:04:38 -0500 Subject: [Kwiver-users] ocv-arrow histogram equalization In-Reply-To: References: <7F74FF27-E0AE-4A04-BE8C-1C0D9FEAB250@kitware.com> <5B9EC111-AA16-4AC4-915D-B04E76970258@kitware.com> Message-ID: Agreed. I?m mostly just highlighting the patterns we have used so far, which I guess is "how it should be done? for now, just for consistency sake, but there may be a better approach. If we can agree that this approach makes sense and handles the cases we care about then we should document it and make it official. ? actually, I suppose it is more practical to document it and make it official anyway and then consider revising when someone complains. ?Matt > On Jan 5, 2018, at 3:56 PM, Matt Brown wrote: > > Thanks for the feedback. Would be nice to funnel this advice into a style guide at some point. > > On Fri, Jan 5, 2018 at 3:46 PM, Matthew Leotta > wrote: > I agree on that point when it comes to name of the algorithm (e.g. string name you pass when registering the algorithms). However, when it comes to naming the .cxx file and the class itself, it can be useful to incorporate the name of the algorithm to make them easier to find in a list of files. Sometimes we give the class in the arrow the same name as the vital algorithm, just in a different namespace, and the name passed to the plugin is the same name as the arrow. For example, ocv::estimate_homography is registered as ?ocv? and derived from vital::estimate_homography. This only works if you can reasonably expect there to be only one implementation of the algorithm provided by that arrow. If this is not the case, another naming scheme we have used is to append another descriptive name to each of these. For example, ocv::extract_descriptors_BRIEF is registered as ?ocv_BRIEF? and is derived from vital::extract_descriptors. There are other variations where ?BRIEF? is replaced by another name. > > ?Matt > > >> On Jan 5, 2018, at 3:22 PM, Linus Sherrill > wrote: >> >> With regard to naming implementations, I do not think you need to add the abstract algorithm name to the new algo name. It seems redundant. When listing the algorithms, the base algo name is listed in addition to the implementation name. >> >> On Fri, Jan 5, 2018 at 2:54 PM, Matthew Leotta > wrote: >> Matt, >> >> In this case I would say image equalization and contrast stretching does match the semantics of ?image_filter?. Image filter should be any sort of image manipulation routine that returns a variant of the image that is enhanced/modified in some way. It is not meant to be a strict definition of ?filter? meaning only operations that can be implemented as a convolution or some other spatially local operation. Think filter in the sense of the filters menu in the GIMP image editing program. >> >> That said, there could be other cases where the input and output types match, but the semantics are different. In that case, I agree with Linus that you should have different abstract algorithms in vital. Imagine an algorithm that take an image and uses it as a query to find and return another image which is most similar in a database. That could also have image in and image out, but I would argue that is not a filter. >> >> Also keep in mind that not every function or algorithm needs to be an abstract algorithm in Vital. The abstract algorithms should represent functional components that you can combine into an application, but where you would reasonably expect to swap out different algorithms for each abstract algorithm. Algorithms best suited for vital/algo are components where you might expect someone to write a paper or a new software project on a better/faster way to do X, or where there are already various competing software packages providing a way to do X. >> >> There may be a point in the future where we have so many image filters that we need to organize them better or create subsets of image filters with more specific applications (like blurring). We are not at that point yet. >> >> ?Matt >> >> >>> On Jan 5, 2018, at 2:04 PM, Matt Brown > wrote: >>> >>> I think that makes sense. When naming the arrow, should there be an attempt to indicate the vital algorithm within the name? For example, for the image_filter algorithm, I called my arrows filter_gaussian_blur and filter_blur, the later half reflecting the primary OCV function being called. >>> >>> On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill > wrote: >>> If we lump all image-in, image-out implementations under one algorithm (e.g. filter_image), they will all appear in one list and it will be hard to find what you are looking for. In this case, if there will be multiple implementations for contrast enhancement, then I think it makes sense to have a base algorithm for contrast_enhancement even though the code looks the same as filter_image. This approach also constrains which algorithm can be configured if it is limited to contrast_enhancement, rather than using the broader category of filter_image. >>> >>> Comments welcome. >>> >>> >>> On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown > wrote: >>> A bit of a semantics question, but I'd like to make an ocv arrow that does histogram equalization and another that stretches contrast in an image. The vital image_filter prototype fits in that an image goes in and one comes out, with the same resolution as the input as is typical of a filter. However, semantically, I'm not sure histogram equalization is really a filter operation. Does it make sense to: >>> Just call it a filter and be done with. >>> Create an effective duplicate of the filter algorithm and call it something more in line with contrast enhancement. >>> plan to rename filter_image to something more generic like process_image. >>> Thanks, >>> Matt >>> >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> https://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >>> >>> >>> -- >>> Linus Sherrill - Staff R&D Engineer >>> Kitware, Inc. >>> 28 Corporate Drive >>> Clifton Park, NY 12065 -8662 >>> E: linus.sherrill at kitware.com >>> P: 518.881.4400 >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> https://public.kitware.com/mailman/listinfo/kwiver-users >> >> >> >> >> -- >> Linus Sherrill - Staff R&D Engineer >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 -8662 >> E: linus.sherrill at kitware.com >> P: 518.881.4400 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Fri Jan 5 21:13:37 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Fri, 5 Jan 2018 21:13:37 -0500 Subject: [Kwiver-users] Unable to find track oracle scoring framework documentation Message-ID: Hi all, For getting started with the Kitware Analytics Toolkit - KWANT, the readme states - Framework requires track_oracle to be enabled/turned on in Kwiver. I have compiled KWIVER with KWIVER_ENABLE_TRACK_ORACLE:BOOL=ON switch. Building the software was successful. However, to understand the track_oracle and scoring framework - https://github.com/Kitware/kwiver/blob/master/track_oracle/scoring_framework/README.markdown - ReadMe is missing. I have created an issue to track the ticket on GitHub. Looking forward to an update on the same. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Sat Jan 6 16:41:10 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Sat, 6 Jan 2018 16:41:10 -0500 Subject: [Kwiver-users] Usage of kwant toolkit Message-ID: Hi all, Based on the documentation, kwant toolkit requires track_oracle to be enabled within kwiver. I have enabled the same in kwiver. In order to use the kwant scoring framework - it would be great if an example/tutorial to run the software is shared/updated on the GitHub readme. Looking forward to a response. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Sun Jan 7 08:22:15 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Sun, 7 Jan 2018 08:22:15 -0500 Subject: [Kwiver-users] Receiving error to run example descriptor.pipe - KWIVER Message-ID: Hi all, In order to check installation of KWIVER software suite and understanding its capabilities, I am trying to run the following example - descriptor.pipe. While running the example an exception is caught with the following message Exception caught: The pipeline cannot be run: The process 'descriptor' of type 'ApplyDescriptor' is a python process and that type of process is not supported by this scheduler. Further, I am trying to understand the purpose of the example descriptor.pipe - if there is a reference to what the example is supposed to perform would help clarify my current level of understanding of the topic. Kindly provide further information to understand the above error and how to resolve the problem. KWIVER is installed with python support. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.hughes at kitware.com Sun Jan 7 23:41:34 2018 From: david.hughes at kitware.com (David Hughes) Date: Sun, 7 Jan 2018 23:41:34 -0500 Subject: [Kwiver-users] Receiving error to run example descriptor.pipe - KWIVER In-Reply-To: References: Message-ID: First of all, a warning on Python related matters--historically, we didn't have much support for python in kwiver. There's a fresh pull request up now with a bunch of fixes and new bindings, but it's not in master yet. So this req The reason that you're getting that error is because the two C++ schedulers won't work with python. The python GIL has its own rules and assumptions for threading, and schedulers designed for C++ aren't necessarily going to abide by them, which is why they throw that exception. The solution is to use the included python scheduler: pythread_per_process. To use it, run the pipeline with the following command: pipeline_runner -p descriptor.pipe *-S pythread_per_process* Keep in mind that until the new branch is in, there's no guarantee that that'll work on master, just that it'll get you past your current error. On Sun, Jan 7, 2018 at 8:22 AM, Ankit Parag Shah wrote: > Hi all, > > In order to check installation of KWIVER software suite and understanding > its capabilities, I am trying to run the following example - > descriptor.pipe. > > While running the example an exception is caught with the following message > > Exception caught: The pipeline cannot be run: The process 'descriptor' of > type 'ApplyDescriptor' is a python process and that type of process is not > supported by this scheduler. > > Further, I am trying to understand the purpose of the example > descriptor.pipe - if there is a reference to what the example is supposed > to perform would help clarify my current level of understanding of the > topic. > > Kindly provide further information to understand the above error and how > to resolve the problem. > KWIVER is installed with python support. > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Mon Jan 8 00:03:35 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Mon, 8 Jan 2018 00:03:35 -0500 Subject: [Kwiver-users] Receiving error to run example descriptor.pipe - KWIVER In-Reply-To: References: Message-ID: Hi David, Indeed, the error is now in the next step - and the python pythread_per_process is being picked up. However, current error is as follows - Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 754, in run self.__target(*self.__args, **self.__kwargs) File "/home/ankit/KWIVER-Software-Scripts/kwiver/build/release/lib/python2.7/dist-packages/sprokit/schedulers/pythread_per_process_scheduler.py", line 115, in _run_process proc.step() File "/home/ankit/KWIVER-Software-Scripts/kwiver/build/release/lib/python2.7/dist-packages/kwiver/processes/ApplyDescriptor.py", line 107, in _step in_img_c = self.grab_input_using_trait('image') File "/home/ankit/KWIVER-Software-Scripts/kwiver/build/release/lib/python2.7/dist-packages/kwiver/kwiver_process.py", line 308, in grab_input_using_trait data = tt.converter_in(pipeline_datum.get_datum_ptr()) TypeError: Unable to convert function return value to a Python type! The signature was (self: sprokit.pipeline.datum.Datum) -> _object Segmentation fault (core dumped) Looking forward to having the new branch checked in to have a successful working pipeline examples. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. On Sun, Jan 7, 2018 at 11:41 PM, David Hughes wrote: > First of all, a warning on Python related matters--historically, we didn't > have much support for python in kwiver. There's a fresh pull request up now > with a bunch of fixes and new bindings, but it's not in master yet. So this > req > > The reason that you're getting that error is because the two C++ > schedulers won't work with python. The python GIL has its own rules and > assumptions for threading, and schedulers designed for C++ aren't > necessarily going to abide by them, which is why they throw that exception. > The solution is to use the included python scheduler: pythread_per_process. > To use it, run the pipeline with the following command: > > pipeline_runner -p descriptor.pipe *-S pythread_per_process* > > Keep in mind that until the new branch is in, there's no guarantee that > that'll work on master, just that it'll get you past your current error. > > On Sun, Jan 7, 2018 at 8:22 AM, Ankit Parag Shah > wrote: > >> Hi all, >> >> In order to check installation of KWIVER software suite and understanding >> its capabilities, I am trying to run the following example - >> descriptor.pipe. >> >> While running the example an exception is caught with the following >> message >> >> Exception caught: The pipeline cannot be run: The process 'descriptor' of >> type 'ApplyDescriptor' is a python process and that type of process is not >> supported by this scheduler. >> >> Further, I am trying to understand the purpose of the example >> descriptor.pipe - if there is a reference to what the example is supposed >> to perform would help clarify my current level of understanding of the >> topic. >> >> Kindly provide further information to understand the above error and how >> to resolve the problem. >> KWIVER is installed with python support. >> >> Kind Regards, >> Ankit Shah >> Masters Student in Language Technologies >> Carnegie Mellon University. >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/kwiver-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Mon Jan 8 20:11:56 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Mon, 8 Jan 2018 20:11:56 -0500 Subject: [Kwiver-users] Usage of kwant toolkit In-Reply-To: References: Message-ID: Hi all, Kindly provide documentation on getting started with KWANT Toolkit. I have been trying to reverse engineer the process, however it is difficult and time consuming process. It would be really helpful to get support to proceed quickly with obtaining information on input, output and commands one can run to get scoring information as output. Looking forward to your response. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. On Sat, Jan 6, 2018 at 4:41 PM, Ankit Parag Shah wrote: > Hi all, > > Based on the documentation, kwant toolkit requires track_oracle to be > enabled within kwiver. I have enabled the same in kwiver. > > In order to use the kwant scoring framework - it would be great if an > example/tutorial to run the software is shared/updated on the GitHub > readme. > > Looking forward to a response. > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roddy.collins at kitware.com Mon Jan 8 22:06:49 2018 From: roddy.collins at kitware.com (Roddy Collins) Date: Mon, 8 Jan 2018 22:06:49 -0500 Subject: [Kwiver-users] Usage of kwant toolkit In-Reply-To: References: Message-ID: Hi Ankit-- We're working on documentation and will have examples up by the end of the week. Thanks -Roddy On Mon, Jan 8, 2018 at 8:11 PM, Ankit Parag Shah wrote: > Hi all, > > Kindly provide documentation on getting started with KWANT Toolkit. > I have been trying to reverse engineer the process, however it is > difficult and time consuming process. > It would be really helpful to get support to proceed quickly with > obtaining information on input, output and commands one can run to get > scoring information as output. > > Looking forward to your response. > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > > On Sat, Jan 6, 2018 at 4:41 PM, Ankit Parag Shah > wrote: > >> Hi all, >> >> Based on the documentation, kwant toolkit requires track_oracle to be >> enabled within kwiver. I have enabled the same in kwiver. >> >> In order to use the kwant scoring framework - it would be great if an >> example/tutorial to run the software is shared/updated on the GitHub >> readme. >> >> Looking forward to a response. >> >> Kind Regards, >> Ankit Shah >> Masters Student in Language Technologies >> Carnegie Mellon University. >> > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Sat Jan 13 03:01:11 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Sat, 13 Jan 2018 03:01:11 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation Message-ID: Hi all, While building DIVA project using the following steps - https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch installation steps, I am facing errors while performing the following installation step. $ cmake ../../src -DCMAKE_BUILD_TYPE=Release Error is as follows: - CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR EIGEN3_VERSION_OK) (Required is at least version "2.91.0") Call Stack (most recent call first): /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) CMake/kwiver-depends-Eigen.cmake:3 (find_package) CMake/kwiver-depends.cmake:4 (include) CMakeLists.txt:138 (include) Upon researching on Google about the error caused and understanding use of EIGEN, there are various hacks suggested to overcome the problem. The problem seems to be within CMAKE which is not able to find EIGEN3_INCLUDE_DIR in path variable. Currently, I am using cmake 3.5.1, may I ask whether it is recommended to perform hacks or it is better to install latest version of cmake available going forward. Looking forward to your response. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bray at kitware.com Sat Jan 13 09:07:55 2018 From: aaron.bray at kitware.com (Aaron Bray) Date: Sat, 13 Jan 2018 09:07:55 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation In-Reply-To: References: Message-ID: CMake version 3.5.1 will work just fine If you are running that cmake command from your intended DIVA build directory (Which should be empty, do not manually build fletch and kwiver to the same target build directory), This will execute the 'Superbuild' control flow in the DIVA CMake files. (A CMake super-build is a project which downloads, configures and builds other projects. ) This control flow from your command should return something like this : *The C compiler identification is GNU 5.4.0* *The CXX compiler identification is GNU 5.4.0* *Check for working C compiler: /usr/bin/cc* *Check for working C compiler: /usr/bin/cc -- works* *Detecting C compiler ABI info* *Detecting C compiler ABI info - done* *Detecting C compile features* *Detecting C compile features - done* *Check for working CXX compiler: /usr/bin/c++* *Check for working CXX compiler: /usr/bin/c++ -- works* *Detecting CXX compiler ABI info* *Detecting CXX compiler ABI info - done* *Detecting CXX compile features* *Detecting CXX compile features - done* *Found Git: /usr/bin/git (found version "2.7.4") * *I am pulling and building fletch!* *I am pulling and building kwiver!* *Configuring done* This is telling you that it will create a Makefile that will download the fletch, kwiver, and kwant source code and build them each, and then build the DIVA code base The Eigen Error mentioned is usually due to running CMake on KWIVER source (from with the KWIVER build directory) (Which should be empty and a different folder or a subfolder from the DIVA build directory) and not providing a fletch_DIR for the KWIVER CMake script to use during it's configuration process Did you successfully build Fletch and KWIVER manually? If so, you should run CMake for DIVA, from an empty build directory like so, to inform the DIVA super build of the location of your KWIVER build directory $ cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH= CMake will return something like this: *Looking for your kwiver...* *I found your kwiver!* *It uses this fletch * *I am pulling and building kwant!* *Configuring done* I suggest using the cmake gui to help see what directories and CMake options are set to help get your build set up (I recommend checking the 'Grouped' and 'Advanced' options in the GUI) you can get it with $sudo apt-get install cmake-qt-gui Thanks, Aaron On Sat, Jan 13, 2018 at 3:01 AM, Ankit Parag Shah wrote: > Hi all, > > While building DIVA project using the following steps - > https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch > installation steps, I am facing errors while performing the following > installation step. > > $ cmake ../../src -DCMAKE_BUILD_TYPE=Release > > Error is as follows: - > > CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 > (message): > Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR EIGEN3_VERSION_OK) > (Required is at least version "2.91.0") > Call Stack (most recent call first): > /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 > (_FPHSA_FAILURE_MESSAGE) > CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) > CMake/kwiver-depends-Eigen.cmake:3 (find_package) > CMake/kwiver-depends.cmake:4 (include) > CMakeLists.txt:138 (include) > > Upon researching on Google about the error caused and understanding use of > EIGEN, there are various hacks suggested to overcome the problem. The > problem seems to be within CMAKE which is not able to find > EIGEN3_INCLUDE_DIR in path variable. > > Currently, I am using cmake 3.5.1, may I ask whether it is recommended to > perform hacks or it is better to install latest version of cmake available > going forward. > > Looking forward to your response. > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Mon Jan 15 16:52:12 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Mon, 15 Jan 2018 16:52:12 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation In-Reply-To: References: Message-ID: Hi all, @Aaron - many thanks for providing the detailed list of steps. I am trying to follow these exact same steps from a new clean directory - With a prebuilt KWIVER path clean/DIVA/build/release# cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH=../../../../kwiver/build/release/ -- Looking for your kwiver... -- I found your kwiver! -- It uses this fletch /home/ankit/KWIVER-Software-Scripts/fletch/build/rel -- You provided a fletch_DIR and a kwiver_DIR, I am going to ignore this fletch_DIR and use the fletch_DIR used to build kwiver -- I am pulling and building kwant! -- Configuring done -- Generating done -- Build files have been written to: /home/ankit/KWIVER-Software- Scripts/clean/DIVA/build/release The above command is successfully completed. However, compilation fails as follows - -- Configuring incomplete, errors occurred! See also "/home/ankit/KWIVER-Software-Scripts/clean/DIVA/build/ release/kwant-build/CMakeFiles/CMakeOutput.log". CMakeFiles/kwant.dir/build.make:106: recipe for target 'DIVA-ExternalProject-Stamps/kwant-configure' failed make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/kwant.dir/all' failed make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 These tests are performed post confirmation of the switches required for installation in KWIVER build release. ============ To check on a clean docker image with no software installed prior using DIVA directly to compile all the relevant dependencies such as kwiver, fletch etc, I ran the following commands. apt-get update yes | apt install wget yes | apt install python yes | apt install vim yes | apt install git yes | apt install cmake yes | apt install build-essential mkdir DIVA cd DIVA mkdir -p build/release mkdir -p build/debug git clone https://github.com/Kitware/DIVA src Then ran the following command from DIVA/build/release path cmake ../../src -DCMAKE_BUILD_TYPE=Release Output - As expected clean -- The C compiler identification is GNU 5.4.0 -- The CXX compiler identification is GNU 5.4.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Git: /usr/bin/git (found version "2.7.4") -- I am pulling and building fletch! -- I am pulling and building kwiver! -- I am pulling and building kwant! -- Configuring done -- Generating done -- Build files have been written to: /mnt/sdd/aps/DIVA/build/release However make -j16 command fails -- Configuring incomplete, errors occurred! See also "/mnt/sdd/aps/DIVA/build/release/kwant-build/CMakeFiles/CMakeOutput.log". CMakeFiles/kwant.dir/build.make:108: recipe for target 'DIVA-ExternalProject-Stamps/kwant-configure' failed make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/kwant.dir/all' failed make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 This error is same as the error with preinstalled KWIVER and a fresh install of DIVA repository. Version of kwant checked out is - Cloning into 'kwant'... Note: checking out 'f53aaaafbd06d7a2c7cbedebfdce94e9dbd83347'. Info obtained from the CMakeOutput.log file. All the above steps run for compiling DIVA are located as part bash script in a private repository - https://github.com/ankitshah009/KWIVER-Software-Scripts which if deemed useful, I could make it public post permission from my advisor. Kindly let me know how to fix the above issue. Looking forward to your response. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. On Sat, Jan 13, 2018 at 9:07 AM, Aaron Bray wrote: > CMake version 3.5.1 will work just fine > > If you are running that cmake command from your intended DIVA build > directory (Which should be empty, do not manually build fletch and kwiver > to the same target build directory), > This will execute the 'Superbuild' control flow in the DIVA CMake files. > (A CMake super-build is a project which downloads, configures and builds > other projects. ) > > This control flow from your command should return something like this : > > *The C compiler identification is GNU 5.4.0* > > *The CXX compiler identification is GNU 5.4.0* > > *Check for working C compiler: /usr/bin/cc* > > *Check for working C compiler: /usr/bin/cc -- works* > > *Detecting C compiler ABI info* > > *Detecting C compiler ABI info - done* > > *Detecting C compile features* > > *Detecting C compile features - done* > > *Check for working CXX compiler: /usr/bin/c++* > > *Check for working CXX compiler: /usr/bin/c++ -- works* > > *Detecting CXX compiler ABI info* > > *Detecting CXX compiler ABI info - done* > > *Detecting CXX compile features* > > *Detecting CXX compile features - done* > > *Found Git: /usr/bin/git (found version "2.7.4") * > > *I am pulling and building fletch!* > > *I am pulling and building kwiver!* > > *Configuring done* > > This is telling you that it will create a Makefile that will download the > fletch, kwiver, and kwant source code and build them each, and then build > the DIVA code base > > The Eigen Error mentioned is usually due to running CMake on KWIVER source > (from with the KWIVER build directory) (Which should be empty and a > different folder or a subfolder from the DIVA build directory) and not > providing a fletch_DIR for the KWIVER CMake script to use during it's > configuration process > > Did you successfully build Fletch and KWIVER manually? > > If so, you should run CMake for DIVA, from an empty build directory like > so, to inform the DIVA super build of the location of your KWIVER build > directory > > $ cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH= > > CMake will return something like this: > > > *Looking for your kwiver...* > > *I found your kwiver!* > *It uses this fletch * > > *I am pulling and building kwant!* > > *Configuring done* > > > > I suggest using the cmake gui to help see what directories and CMake > options are set to help get your build set up > > (I recommend checking the 'Grouped' and 'Advanced' options in the GUI) > > > you can get it with > > $sudo apt-get install cmake-qt-gui > > > Thanks, > > > Aaron > > > On Sat, Jan 13, 2018 at 3:01 AM, Ankit Parag Shah > wrote: > >> Hi all, >> >> While building DIVA project using the following steps - >> https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch >> installation steps, I am facing errors while performing the following >> installation step. >> >> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release >> >> Error is as follows: - >> >> CMake Error at /usr/share/cmake-3.5/Modules/F >> indPackageHandleStandardArgs.cmake:148 (message): >> Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR EIGEN3_VERSION_OK) >> (Required is at least version "2.91.0") >> Call Stack (most recent call first): >> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 >> (_FPHSA_FAILURE_MESSAGE) >> CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) >> CMake/kwiver-depends-Eigen.cmake:3 (find_package) >> CMake/kwiver-depends.cmake:4 (include) >> CMakeLists.txt:138 (include) >> >> Upon researching on Google about the error caused and understanding use >> of EIGEN, there are various hacks suggested to overcome the problem. The >> problem seems to be within CMAKE which is not able to find >> EIGEN3_INCLUDE_DIR in path variable. >> >> Currently, I am using cmake 3.5.1, may I ask whether it is recommended to >> perform hacks or it is better to install latest version of cmake available >> going forward. >> >> Looking forward to your response. >> >> Kind Regards, >> Ankit Shah >> Masters Student in Language Technologies >> Carnegie Mellon University. >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> https://public.kitware.com/mailman/listinfo/kwiver-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bray at kitware.com Mon Jan 15 17:13:23 2018 From: aaron.bray at kitware.com (Aaron Bray) Date: Mon, 15 Jan 2018 17:13:23 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation In-Reply-To: References: Message-ID: Thanks for the input Ankit! I will check it all out and get back to you! On Jan 15, 2018 1:52 PM, "Ankit Parag Shah" wrote: > Hi all, > > @Aaron - many thanks for providing the detailed list of steps. > > I am trying to follow these exact same steps from a new clean directory - > With a prebuilt KWIVER path > > clean/DIVA/build/release# cmake ../../src -DCMAKE_BUILD_TYPE=Release > -Dkwiver_DIR:PATH=../../../../kwiver/build/release/ > -- Looking for your kwiver... > -- I found your kwiver! > -- It uses this fletch /home/ankit/KWIVER-Software-Sc > ripts/fletch/build/rel > -- You provided a fletch_DIR and a kwiver_DIR, I am going to ignore this > fletch_DIR and use the fletch_DIR used to build kwiver > -- I am pulling and building kwant! > -- Configuring done > -- Generating done > -- Build files have been written to: /home/ankit/KWIVER-Software-Sc > ripts/clean/DIVA/build/release > > The above command is successfully completed. > > However, compilation fails as follows - > > -- Configuring incomplete, errors occurred! > See also "/home/ankit/KWIVER-Software-Scripts/clean/DIVA/build/releas > e/kwant-build/CMakeFiles/CMakeOutput.log". > CMakeFiles/kwant.dir/build.make:106: recipe for target > 'DIVA-ExternalProject-Stamps/kwant-configure' failed > make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 > CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/kwant.dir/all' > failed > make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 > Makefile:83: recipe for target 'all' failed > make: *** [all] Error 2 > > These tests are performed post confirmation of the switches required for > installation in KWIVER build release. > > ============ > > To check on a clean docker image with no software installed prior using > DIVA directly to compile all the relevant dependencies such as kwiver, > fletch etc, I ran the following commands. > > apt-get update > yes | apt install wget > yes | apt install python > yes | apt install vim > yes | apt install git > yes | apt install cmake > yes | apt install build-essential > mkdir DIVA > cd DIVA > mkdir -p build/release > mkdir -p build/debug > git clone https://github.com/Kitware/DIVA src > > Then ran the following command from DIVA/build/release path > > cmake ../../src -DCMAKE_BUILD_TYPE=Release > > Output - As expected clean > -- The C compiler identification is GNU 5.4.0 > -- The CXX compiler identification is GNU 5.4.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Found Git: /usr/bin/git (found version "2.7.4") > -- I am pulling and building fletch! > -- I am pulling and building kwiver! > -- I am pulling and building kwant! > -- Configuring done > -- Generating done > -- Build files have been written to: /mnt/sdd/aps/DIVA/build/release > > However make -j16 command fails > > -- Configuring incomplete, errors occurred! > See also "/mnt/sdd/aps/DIVA/build/release/kwant-build/ > CMakeFiles/CMakeOutput.log". > CMakeFiles/kwant.dir/build.make:108: recipe for target > 'DIVA-ExternalProject-Stamps/kwant-configure' failed > make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 > CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/kwant.dir/all' > failed > make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 > Makefile:83: recipe for target 'all' failed > make: *** [all] Error 2 > > This error is same as the error with preinstalled KWIVER and a fresh > install of DIVA repository. > > Version of kwant checked out is - > > Cloning into 'kwant'... > Note: checking out 'f53aaaafbd06d7a2c7cbedebfdce94e9dbd83347'. > > Info obtained from the CMakeOutput.log file. > > All the above steps run for compiling DIVA are located as part bash script > in a private repository - https://github.com/ankitshah009/KWIVER-Software- > Scripts which if deemed useful, I could make it public post permission > from my advisor. > Kindly let me know how to fix the above issue. > > Looking forward to your response. > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > > On Sat, Jan 13, 2018 at 9:07 AM, Aaron Bray > wrote: > >> CMake version 3.5.1 will work just fine >> >> If you are running that cmake command from your intended DIVA build >> directory (Which should be empty, do not manually build fletch and kwiver >> to the same target build directory), >> This will execute the 'Superbuild' control flow in the DIVA CMake files. >> (A CMake super-build is a project which downloads, configures and builds >> other projects. ) >> >> This control flow from your command should return something like this : >> >> *The C compiler identification is GNU 5.4.0* >> >> *The CXX compiler identification is GNU 5.4.0* >> >> *Check for working C compiler: /usr/bin/cc* >> >> *Check for working C compiler: /usr/bin/cc -- works* >> >> *Detecting C compiler ABI info* >> >> *Detecting C compiler ABI info - done* >> >> *Detecting C compile features* >> >> *Detecting C compile features - done* >> >> *Check for working CXX compiler: /usr/bin/c++* >> >> *Check for working CXX compiler: /usr/bin/c++ -- works* >> >> *Detecting CXX compiler ABI info* >> >> *Detecting CXX compiler ABI info - done* >> >> *Detecting CXX compile features* >> >> *Detecting CXX compile features - done* >> >> *Found Git: /usr/bin/git (found version "2.7.4") * >> >> *I am pulling and building fletch!* >> >> *I am pulling and building kwiver!* >> >> *Configuring done* >> >> This is telling you that it will create a Makefile that will download the >> fletch, kwiver, and kwant source code and build them each, and then build >> the DIVA code base >> >> The Eigen Error mentioned is usually due to running CMake on KWIVER >> source (from with the KWIVER build directory) (Which should be empty and a >> different folder or a subfolder from the DIVA build directory) and not >> providing a fletch_DIR for the KWIVER CMake script to use during it's >> configuration process >> >> Did you successfully build Fletch and KWIVER manually? >> >> If so, you should run CMake for DIVA, from an empty build directory like >> so, to inform the DIVA super build of the location of your KWIVER build >> directory >> >> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH= >> >> CMake will return something like this: >> >> >> *Looking for your kwiver...* >> >> *I found your kwiver!* >> *It uses this fletch * >> >> *I am pulling and building kwant!* >> >> *Configuring done* >> >> >> >> I suggest using the cmake gui to help see what directories and CMake >> options are set to help get your build set up >> >> (I recommend checking the 'Grouped' and 'Advanced' options in the GUI) >> >> >> you can get it with >> >> $sudo apt-get install cmake-qt-gui >> >> >> Thanks, >> >> >> Aaron >> >> >> On Sat, Jan 13, 2018 at 3:01 AM, Ankit Parag Shah >> wrote: >> >>> Hi all, >>> >>> While building DIVA project using the following steps - >>> https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch >>> installation steps, I am facing errors while performing the following >>> installation step. >>> >>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release >>> >>> Error is as follows: - >>> >>> CMake Error at /usr/share/cmake-3.5/Modules/F >>> indPackageHandleStandardArgs.cmake:148 (message): >>> Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR EIGEN3_VERSION_OK) >>> (Required is at least version "2.91.0") >>> Call Stack (most recent call first): >>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 >>> (_FPHSA_FAILURE_MESSAGE) >>> CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) >>> CMake/kwiver-depends-Eigen.cmake:3 (find_package) >>> CMake/kwiver-depends.cmake:4 (include) >>> CMakeLists.txt:138 (include) >>> >>> Upon researching on Google about the error caused and understanding use >>> of EIGEN, there are various hacks suggested to overcome the problem. The >>> problem seems to be within CMAKE which is not able to find >>> EIGEN3_INCLUDE_DIR in path variable. >>> >>> Currently, I am using cmake 3.5.1, may I ask whether it is recommended >>> to perform hacks or it is better to install latest version of cmake >>> available going forward. >>> >>> Looking forward to your response. >>> >>> Kind Regards, >>> Ankit Shah >>> Masters Student in Language Technologies >>> Carnegie Mellon University. >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> https://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Mon Jan 15 17:28:53 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Mon, 15 Jan 2018 17:28:53 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation In-Reply-To: References: Message-ID: Hi Aaron, Thank you for your response. There is a pull request open to fix linking issues on KWANT on windows - https://github.com/Kitware/kwant/pull/9/commits/ a3766b22772c6f39717b23b34c7e7d194cd77f1e - Fix linking issues in windows I am able to see that the current version of kwant being compiled on is same as error prone linking version of above pull request. Further, it is stuck in kwant-patch step within build.make 108 line which might get fixed with the pull request. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. On Mon, Jan 15, 2018 at 5:13 PM, Aaron Bray wrote: > Thanks for the input Ankit! > > I will check it all out and get back to you! > > On Jan 15, 2018 1:52 PM, "Ankit Parag Shah" wrote: > >> Hi all, >> >> @Aaron - many thanks for providing the detailed list of steps. >> >> I am trying to follow these exact same steps from a new clean directory - >> With a prebuilt KWIVER path >> >> clean/DIVA/build/release# cmake ../../src -DCMAKE_BUILD_TYPE=Release >> -Dkwiver_DIR:PATH=../../../../kwiver/build/release/ >> -- Looking for your kwiver... >> -- I found your kwiver! >> -- It uses this fletch /home/ankit/KWIVER-Software-Sc >> ripts/fletch/build/rel >> -- You provided a fletch_DIR and a kwiver_DIR, I am going to ignore this >> fletch_DIR and use the fletch_DIR used to build kwiver >> -- I am pulling and building kwant! >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /home/ankit/KWIVER-Software-Sc >> ripts/clean/DIVA/build/release >> >> The above command is successfully completed. >> >> However, compilation fails as follows - >> >> -- Configuring incomplete, errors occurred! >> See also "/home/ankit/KWIVER-Software-Scripts/clean/DIVA/build/releas >> e/kwant-build/CMakeFiles/CMakeOutput.log". >> CMakeFiles/kwant.dir/build.make:106: recipe for target >> 'DIVA-ExternalProject-Stamps/kwant-configure' failed >> make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 >> CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/kwant.dir/all' >> failed >> make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 >> Makefile:83: recipe for target 'all' failed >> make: *** [all] Error 2 >> >> These tests are performed post confirmation of the switches required for >> installation in KWIVER build release. >> >> ============ >> >> To check on a clean docker image with no software installed prior using >> DIVA directly to compile all the relevant dependencies such as kwiver, >> fletch etc, I ran the following commands. >> >> apt-get update >> yes | apt install wget >> yes | apt install python >> yes | apt install vim >> yes | apt install git >> yes | apt install cmake >> yes | apt install build-essential >> mkdir DIVA >> cd DIVA >> mkdir -p build/release >> mkdir -p build/debug >> git clone https://github.com/Kitware/DIVA src >> >> Then ran the following command from DIVA/build/release path >> >> cmake ../../src -DCMAKE_BUILD_TYPE=Release >> >> Output - As expected clean >> -- The C compiler identification is GNU 5.4.0 >> -- The CXX compiler identification is GNU 5.4.0 >> -- Check for working C compiler: /usr/bin/cc >> -- Check for working C compiler: /usr/bin/cc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Detecting C compile features >> -- Detecting C compile features - done >> -- Check for working CXX compiler: /usr/bin/c++ >> -- Check for working CXX compiler: /usr/bin/c++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Detecting CXX compile features >> -- Detecting CXX compile features - done >> -- Found Git: /usr/bin/git (found version "2.7.4") >> -- I am pulling and building fletch! >> -- I am pulling and building kwiver! >> -- I am pulling and building kwant! >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /mnt/sdd/aps/DIVA/build/release >> >> However make -j16 command fails >> >> -- Configuring incomplete, errors occurred! >> See also "/mnt/sdd/aps/DIVA/build/release/kwant-build/CMakeFiles/CMak >> eOutput.log". >> CMakeFiles/kwant.dir/build.make:108: recipe for target >> 'DIVA-ExternalProject-Stamps/kwant-configure' failed >> make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 >> CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/kwant.dir/all' >> failed >> make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 >> Makefile:83: recipe for target 'all' failed >> make: *** [all] Error 2 >> >> This error is same as the error with preinstalled KWIVER and a fresh >> install of DIVA repository. >> >> Version of kwant checked out is - >> >> Cloning into 'kwant'... >> Note: checking out 'f53aaaafbd06d7a2c7cbedebfdce94e9dbd83347'. >> >> Info obtained from the CMakeOutput.log file. >> >> All the above steps run for compiling DIVA are located as part bash >> script in a private repository - https://github.com/ankitshah00 >> 9/KWIVER-Software-Scripts which if deemed useful, I could make it public >> post permission from my advisor. >> Kindly let me know how to fix the above issue. >> >> Looking forward to your response. >> >> Kind Regards, >> Ankit Shah >> Masters Student in Language Technologies >> Carnegie Mellon University. >> >> On Sat, Jan 13, 2018 at 9:07 AM, Aaron Bray >> wrote: >> >>> CMake version 3.5.1 will work just fine >>> >>> If you are running that cmake command from your intended DIVA build >>> directory (Which should be empty, do not manually build fletch and kwiver >>> to the same target build directory), >>> This will execute the 'Superbuild' control flow in the DIVA CMake files. >>> (A CMake super-build is a project which downloads, configures and >>> builds other projects. ) >>> >>> This control flow from your command should return something like this : >>> >>> *The C compiler identification is GNU 5.4.0* >>> >>> *The CXX compiler identification is GNU 5.4.0* >>> >>> *Check for working C compiler: /usr/bin/cc* >>> >>> *Check for working C compiler: /usr/bin/cc -- works* >>> >>> *Detecting C compiler ABI info* >>> >>> *Detecting C compiler ABI info - done* >>> >>> *Detecting C compile features* >>> >>> *Detecting C compile features - done* >>> >>> *Check for working CXX compiler: /usr/bin/c++* >>> >>> *Check for working CXX compiler: /usr/bin/c++ -- works* >>> >>> *Detecting CXX compiler ABI info* >>> >>> *Detecting CXX compiler ABI info - done* >>> >>> *Detecting CXX compile features* >>> >>> *Detecting CXX compile features - done* >>> >>> *Found Git: /usr/bin/git (found version "2.7.4") * >>> >>> *I am pulling and building fletch!* >>> >>> *I am pulling and building kwiver!* >>> >>> *Configuring done* >>> >>> This is telling you that it will create a Makefile that will download >>> the fletch, kwiver, and kwant source code and build them each, and then >>> build the DIVA code base >>> >>> The Eigen Error mentioned is usually due to running CMake on KWIVER >>> source (from with the KWIVER build directory) (Which should be empty and a >>> different folder or a subfolder from the DIVA build directory) and not >>> providing a fletch_DIR for the KWIVER CMake script to use during it's >>> configuration process >>> >>> Did you successfully build Fletch and KWIVER manually? >>> >>> If so, you should run CMake for DIVA, from an empty build directory like >>> so, to inform the DIVA super build of the location of your KWIVER build >>> directory >>> >>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH= >>> >>> CMake will return something like this: >>> >>> >>> *Looking for your kwiver...* >>> >>> *I found your kwiver!* >>> *It uses this fletch * >>> >>> *I am pulling and building kwant!* >>> >>> *Configuring done* >>> >>> >>> >>> I suggest using the cmake gui to help see what directories and CMake >>> options are set to help get your build set up >>> >>> (I recommend checking the 'Grouped' and 'Advanced' options in the GUI) >>> >>> >>> you can get it with >>> >>> $sudo apt-get install cmake-qt-gui >>> >>> >>> Thanks, >>> >>> >>> Aaron >>> >>> >>> On Sat, Jan 13, 2018 at 3:01 AM, Ankit Parag Shah >>> wrote: >>> >>>> Hi all, >>>> >>>> While building DIVA project using the following steps - >>>> https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch >>>> installation steps, I am facing errors while performing the following >>>> installation step. >>>> >>>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release >>>> >>>> Error is as follows: - >>>> >>>> CMake Error at /usr/share/cmake-3.5/Modules/F >>>> indPackageHandleStandardArgs.cmake:148 (message): >>>> Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR EIGEN3_VERSION_OK) >>>> (Required is at least version "2.91.0") >>>> Call Stack (most recent call first): >>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 >>>> (_FPHSA_FAILURE_MESSAGE) >>>> CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) >>>> CMake/kwiver-depends-Eigen.cmake:3 (find_package) >>>> CMake/kwiver-depends.cmake:4 (include) >>>> CMakeLists.txt:138 (include) >>>> >>>> Upon researching on Google about the error caused and understanding use >>>> of EIGEN, there are various hacks suggested to overcome the problem. The >>>> problem seems to be within CMAKE which is not able to find >>>> EIGEN3_INCLUDE_DIR in path variable. >>>> >>>> Currently, I am using cmake 3.5.1, may I ask whether it is recommended >>>> to perform hacks or it is better to install latest version of cmake >>>> available going forward. >>>> >>>> Looking forward to your response. >>>> >>>> Kind Regards, >>>> Ankit Shah >>>> Masters Student in Language Technologies >>>> Carnegie Mellon University. >>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> https://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aps1 at andrew.cmu.edu Wed Jan 17 00:18:01 2018 From: aps1 at andrew.cmu.edu (Ankit Parag Shah) Date: Wed, 17 Jan 2018 00:18:01 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation In-Reply-To: References: Message-ID: Hi all, Please provide further inputs with above error. I have tried a few things and making changes as per open pull requests to the compilation code which doesn't seem to work. Eagerly waiting for your response. Kind Regards, Ankit Shah Masters Student in Language Technologies Carnegie Mellon University. On Mon, Jan 15, 2018 at 5:28 PM, Ankit Parag Shah wrote: > Hi Aaron, > > Thank you for your response. > > There is a pull request open to fix linking issues on KWANT on windows - > https://github.com/Kitware/kwant/pull/9/commits/a3766b22772c6f39717b23b34c7e7d194cd77f1e > - Fix linking issues in windows > > I am able to see that the current version of kwant being compiled on is > same as error prone linking version of above pull request. Further, it is > stuck in kwant-patch step within build.make 108 line which might get fixed > with the pull request. > > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > > On Mon, Jan 15, 2018 at 5:13 PM, Aaron Bray > wrote: > >> Thanks for the input Ankit! >> >> I will check it all out and get back to you! >> >> On Jan 15, 2018 1:52 PM, "Ankit Parag Shah" wrote: >> >>> Hi all, >>> >>> @Aaron - many thanks for providing the detailed list of steps. >>> >>> I am trying to follow these exact same steps from a new clean directory >>> - With a prebuilt KWIVER path >>> >>> clean/DIVA/build/release# cmake ../../src -DCMAKE_BUILD_TYPE=Release >>> -Dkwiver_DIR:PATH=../../../../kwiver/build/release/ >>> -- Looking for your kwiver... >>> -- I found your kwiver! >>> -- It uses this fletch /home/ankit/KWIVER-Software-Sc >>> ripts/fletch/build/rel >>> -- You provided a fletch_DIR and a kwiver_DIR, I am going to ignore this >>> fletch_DIR and use the fletch_DIR used to build kwiver >>> -- I am pulling and building kwant! >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: /home/ankit/KWIVER-Software-Sc >>> ripts/clean/DIVA/build/release >>> >>> The above command is successfully completed. >>> >>> However, compilation fails as follows - >>> >>> -- Configuring incomplete, errors occurred! >>> See also "/home/ankit/KWIVER-Software-Scripts/clean/DIVA/build/releas >>> e/kwant-build/CMakeFiles/CMakeOutput.log". >>> CMakeFiles/kwant.dir/build.make:106: recipe for target >>> 'DIVA-ExternalProject-Stamps/kwant-configure' failed >>> make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 >>> CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/kwant.dir/all' >>> failed >>> make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 >>> Makefile:83: recipe for target 'all' failed >>> make: *** [all] Error 2 >>> >>> These tests are performed post confirmation of the switches required for >>> installation in KWIVER build release. >>> >>> ============ >>> >>> To check on a clean docker image with no software installed prior using >>> DIVA directly to compile all the relevant dependencies such as kwiver, >>> fletch etc, I ran the following commands. >>> >>> apt-get update >>> yes | apt install wget >>> yes | apt install python >>> yes | apt install vim >>> yes | apt install git >>> yes | apt install cmake >>> yes | apt install build-essential >>> mkdir DIVA >>> cd DIVA >>> mkdir -p build/release >>> mkdir -p build/debug >>> git clone https://github.com/Kitware/DIVA src >>> >>> Then ran the following command from DIVA/build/release path >>> >>> cmake ../../src -DCMAKE_BUILD_TYPE=Release >>> >>> Output - As expected clean >>> -- The C compiler identification is GNU 5.4.0 >>> -- The CXX compiler identification is GNU 5.4.0 >>> -- Check for working C compiler: /usr/bin/cc >>> -- Check for working C compiler: /usr/bin/cc -- works >>> -- Detecting C compiler ABI info >>> -- Detecting C compiler ABI info - done >>> -- Detecting C compile features >>> -- Detecting C compile features - done >>> -- Check for working CXX compiler: /usr/bin/c++ >>> -- Check for working CXX compiler: /usr/bin/c++ -- works >>> -- Detecting CXX compiler ABI info >>> -- Detecting CXX compiler ABI info - done >>> -- Detecting CXX compile features >>> -- Detecting CXX compile features - done >>> -- Found Git: /usr/bin/git (found version "2.7.4") >>> -- I am pulling and building fletch! >>> -- I am pulling and building kwiver! >>> -- I am pulling and building kwant! >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: /mnt/sdd/aps/DIVA/build/release >>> >>> However make -j16 command fails >>> >>> -- Configuring incomplete, errors occurred! >>> See also "/mnt/sdd/aps/DIVA/build/release/kwant-build/CMakeFiles/CMak >>> eOutput.log". >>> CMakeFiles/kwant.dir/build.make:108: recipe for target >>> 'DIVA-ExternalProject-Stamps/kwant-configure' failed >>> make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 >>> CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/kwant.dir/all' >>> failed >>> make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 >>> Makefile:83: recipe for target 'all' failed >>> make: *** [all] Error 2 >>> >>> This error is same as the error with preinstalled KWIVER and a fresh >>> install of DIVA repository. >>> >>> Version of kwant checked out is - >>> >>> Cloning into 'kwant'... >>> Note: checking out 'f53aaaafbd06d7a2c7cbedebfdce94e9dbd83347'. >>> >>> Info obtained from the CMakeOutput.log file. >>> >>> All the above steps run for compiling DIVA are located as part bash >>> script in a private repository - https://github.com/ankitshah00 >>> 9/KWIVER-Software-Scripts which if deemed useful, I could make it >>> public post permission from my advisor. >>> Kindly let me know how to fix the above issue. >>> >>> Looking forward to your response. >>> >>> Kind Regards, >>> Ankit Shah >>> Masters Student in Language Technologies >>> Carnegie Mellon University. >>> >>> On Sat, Jan 13, 2018 at 9:07 AM, Aaron Bray >>> wrote: >>> >>>> CMake version 3.5.1 will work just fine >>>> >>>> If you are running that cmake command from your intended DIVA build >>>> directory (Which should be empty, do not manually build fletch and kwiver >>>> to the same target build directory), >>>> This will execute the 'Superbuild' control flow in the DIVA CMake files. >>>> (A CMake super-build is a project which downloads, configures and >>>> builds other projects. ) >>>> >>>> This control flow from your command should return something like this : >>>> >>>> *The C compiler identification is GNU 5.4.0* >>>> >>>> *The CXX compiler identification is GNU 5.4.0* >>>> >>>> *Check for working C compiler: /usr/bin/cc* >>>> >>>> *Check for working C compiler: /usr/bin/cc -- works* >>>> >>>> *Detecting C compiler ABI info* >>>> >>>> *Detecting C compiler ABI info - done* >>>> >>>> *Detecting C compile features* >>>> >>>> *Detecting C compile features - done* >>>> >>>> *Check for working CXX compiler: /usr/bin/c++* >>>> >>>> *Check for working CXX compiler: /usr/bin/c++ -- works* >>>> >>>> *Detecting CXX compiler ABI info* >>>> >>>> *Detecting CXX compiler ABI info - done* >>>> >>>> *Detecting CXX compile features* >>>> >>>> *Detecting CXX compile features - done* >>>> >>>> *Found Git: /usr/bin/git (found version "2.7.4") * >>>> >>>> *I am pulling and building fletch!* >>>> >>>> *I am pulling and building kwiver!* >>>> >>>> *Configuring done* >>>> >>>> This is telling you that it will create a Makefile that will download >>>> the fletch, kwiver, and kwant source code and build them each, and then >>>> build the DIVA code base >>>> >>>> The Eigen Error mentioned is usually due to running CMake on KWIVER >>>> source (from with the KWIVER build directory) (Which should be empty and a >>>> different folder or a subfolder from the DIVA build directory) and not >>>> providing a fletch_DIR for the KWIVER CMake script to use during it's >>>> configuration process >>>> >>>> Did you successfully build Fletch and KWIVER manually? >>>> >>>> If so, you should run CMake for DIVA, from an empty build directory >>>> like so, to inform the DIVA super build of the location of your KWIVER >>>> build directory >>>> >>>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH= >>>> >>>> CMake will return something like this: >>>> >>>> >>>> *Looking for your kwiver...* >>>> >>>> *I found your kwiver!* >>>> *It uses this fletch * >>>> >>>> *I am pulling and building kwant!* >>>> >>>> *Configuring done* >>>> >>>> >>>> >>>> I suggest using the cmake gui to help see what directories and CMake >>>> options are set to help get your build set up >>>> >>>> (I recommend checking the 'Grouped' and 'Advanced' options in the GUI) >>>> >>>> >>>> you can get it with >>>> >>>> $sudo apt-get install cmake-qt-gui >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Aaron >>>> >>>> >>>> On Sat, Jan 13, 2018 at 3:01 AM, Ankit Parag Shah >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> While building DIVA project using the following steps - >>>>> https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch >>>>> installation steps, I am facing errors while performing the following >>>>> installation step. >>>>> >>>>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release >>>>> >>>>> Error is as follows: - >>>>> >>>>> CMake Error at /usr/share/cmake-3.5/Modules/F >>>>> indPackageHandleStandardArgs.cmake:148 (message): >>>>> Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR EIGEN3_VERSION_OK) >>>>> (Required is at least version "2.91.0") >>>>> Call Stack (most recent call first): >>>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 >>>>> (_FPHSA_FAILURE_MESSAGE) >>>>> CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) >>>>> CMake/kwiver-depends-Eigen.cmake:3 (find_package) >>>>> CMake/kwiver-depends.cmake:4 (include) >>>>> CMakeLists.txt:138 (include) >>>>> >>>>> Upon researching on Google about the error caused and understanding >>>>> use of EIGEN, there are various hacks suggested to overcome the problem. >>>>> The problem seems to be within CMAKE which is not able to find >>>>> EIGEN3_INCLUDE_DIR in path variable. >>>>> >>>>> Currently, I am using cmake 3.5.1, may I ask whether it is recommended >>>>> to perform hacks or it is better to install latest version of cmake >>>>> available going forward. >>>>> >>>>> Looking forward to your response. >>>>> >>>>> Kind Regards, >>>>> Ankit Shah >>>>> Masters Student in Language Technologies >>>>> Carnegie Mellon University. >>>>> >>>>> _______________________________________________ >>>>> Kwiver-users mailing list >>>>> Kwiver-users at public.kitware.com >>>>> https://public.kitware.com/mailman/listinfo/kwiver-users >>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bray at kitware.com Wed Jan 17 04:13:57 2018 From: aaron.bray at kitware.com (Aaron Bray) Date: Wed, 17 Jan 2018 04:13:57 -0500 Subject: [Kwiver-users] Recommended version of CMAKE to be used for DIVA installation In-Reply-To: References: Message-ID: We are landing a few branches to get a cohesive superbuild, I will keep you posted when everything gets in and in sync On Wed, Jan 17, 2018 at 12:18 AM, Ankit Parag Shah wrote: > Hi all, > > Please provide further inputs with above error. > I have tried a few things and making changes as per open pull requests to > the compilation code which doesn't seem to work. > Eagerly waiting for your response. > > Kind Regards, > Ankit Shah > Masters Student in Language Technologies > Carnegie Mellon University. > > On Mon, Jan 15, 2018 at 5:28 PM, Ankit Parag Shah > wrote: > >> Hi Aaron, >> >> Thank you for your response. >> >> There is a pull request open to fix linking issues on KWANT on windows - >> https://github.com/Kitware/kwant/pull/9/commits/a3766b22772c6f39717b23b34c7e7d194cd77f1e >> - Fix linking issues in windows >> >> I am able to see that the current version of kwant being compiled on is >> same as error prone linking version of above pull request. Further, it is >> stuck in kwant-patch step within build.make 108 line which might get fixed >> with the pull request. >> >> >> Kind Regards, >> Ankit Shah >> Masters Student in Language Technologies >> Carnegie Mellon University. >> >> On Mon, Jan 15, 2018 at 5:13 PM, Aaron Bray >> wrote: >> >>> Thanks for the input Ankit! >>> >>> I will check it all out and get back to you! >>> >>> On Jan 15, 2018 1:52 PM, "Ankit Parag Shah" wrote: >>> >>>> Hi all, >>>> >>>> @Aaron - many thanks for providing the detailed list of steps. >>>> >>>> I am trying to follow these exact same steps from a new clean directory >>>> - With a prebuilt KWIVER path >>>> >>>> clean/DIVA/build/release# cmake ../../src -DCMAKE_BUILD_TYPE=Release >>>> -Dkwiver_DIR:PATH=../../../../kwiver/build/release/ >>>> -- Looking for your kwiver... >>>> -- I found your kwiver! >>>> -- It uses this fletch /home/ankit/KWIVER-Software-Sc >>>> ripts/fletch/build/rel >>>> -- You provided a fletch_DIR and a kwiver_DIR, I am going to ignore >>>> this fletch_DIR and use the fletch_DIR used to build kwiver >>>> -- I am pulling and building kwant! >>>> -- Configuring done >>>> -- Generating done >>>> -- Build files have been written to: /home/ankit/KWIVER-Software-Sc >>>> ripts/clean/DIVA/build/release >>>> >>>> The above command is successfully completed. >>>> >>>> However, compilation fails as follows - >>>> >>>> -- Configuring incomplete, errors occurred! >>>> See also "/home/ankit/KWIVER-Software-Scripts/clean/DIVA/build/releas >>>> e/kwant-build/CMakeFiles/CMakeOutput.log". >>>> CMakeFiles/kwant.dir/build.make:106: recipe for target >>>> 'DIVA-ExternalProject-Stamps/kwant-configure' failed >>>> make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 >>>> CMakeFiles/Makefile2:104: recipe for target 'CMakeFiles/kwant.dir/all' >>>> failed >>>> make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 >>>> Makefile:83: recipe for target 'all' failed >>>> make: *** [all] Error 2 >>>> >>>> These tests are performed post confirmation of the switches required >>>> for installation in KWIVER build release. >>>> >>>> ============ >>>> >>>> To check on a clean docker image with no software installed prior using >>>> DIVA directly to compile all the relevant dependencies such as kwiver, >>>> fletch etc, I ran the following commands. >>>> >>>> apt-get update >>>> yes | apt install wget >>>> yes | apt install python >>>> yes | apt install vim >>>> yes | apt install git >>>> yes | apt install cmake >>>> yes | apt install build-essential >>>> mkdir DIVA >>>> cd DIVA >>>> mkdir -p build/release >>>> mkdir -p build/debug >>>> git clone https://github.com/Kitware/DIVA src >>>> >>>> Then ran the following command from DIVA/build/release path >>>> >>>> cmake ../../src -DCMAKE_BUILD_TYPE=Release >>>> >>>> Output - As expected clean >>>> -- The C compiler identification is GNU 5.4.0 >>>> -- The CXX compiler identification is GNU 5.4.0 >>>> -- Check for working C compiler: /usr/bin/cc >>>> -- Check for working C compiler: /usr/bin/cc -- works >>>> -- Detecting C compiler ABI info >>>> -- Detecting C compiler ABI info - done >>>> -- Detecting C compile features >>>> -- Detecting C compile features - done >>>> -- Check for working CXX compiler: /usr/bin/c++ >>>> -- Check for working CXX compiler: /usr/bin/c++ -- works >>>> -- Detecting CXX compiler ABI info >>>> -- Detecting CXX compiler ABI info - done >>>> -- Detecting CXX compile features >>>> -- Detecting CXX compile features - done >>>> -- Found Git: /usr/bin/git (found version "2.7.4") >>>> -- I am pulling and building fletch! >>>> -- I am pulling and building kwiver! >>>> -- I am pulling and building kwant! >>>> -- Configuring done >>>> -- Generating done >>>> -- Build files have been written to: /mnt/sdd/aps/DIVA/build/release >>>> >>>> However make -j16 command fails >>>> >>>> -- Configuring incomplete, errors occurred! >>>> See also "/mnt/sdd/aps/DIVA/build/release/kwant-build/CMakeFiles/CMak >>>> eOutput.log". >>>> CMakeFiles/kwant.dir/build.make:108: recipe for target >>>> 'DIVA-ExternalProject-Stamps/kwant-configure' failed >>>> make[2]: *** [DIVA-ExternalProject-Stamps/kwant-configure] Error 1 >>>> CMakeFiles/Makefile2:181: recipe for target 'CMakeFiles/kwant.dir/all' >>>> failed >>>> make[1]: *** [CMakeFiles/kwant.dir/all] Error 2 >>>> Makefile:83: recipe for target 'all' failed >>>> make: *** [all] Error 2 >>>> >>>> This error is same as the error with preinstalled KWIVER and a fresh >>>> install of DIVA repository. >>>> >>>> Version of kwant checked out is - >>>> >>>> Cloning into 'kwant'... >>>> Note: checking out 'f53aaaafbd06d7a2c7cbedebfdce94e9dbd83347'. >>>> >>>> Info obtained from the CMakeOutput.log file. >>>> >>>> All the above steps run for compiling DIVA are located as part bash >>>> script in a private repository - https://github.com/ankitshah00 >>>> 9/KWIVER-Software-Scripts which if deemed useful, I could make it >>>> public post permission from my advisor. >>>> Kindly let me know how to fix the above issue. >>>> >>>> Looking forward to your response. >>>> >>>> Kind Regards, >>>> Ankit Shah >>>> Masters Student in Language Technologies >>>> Carnegie Mellon University. >>>> >>>> On Sat, Jan 13, 2018 at 9:07 AM, Aaron Bray >>>> wrote: >>>> >>>>> CMake version 3.5.1 will work just fine >>>>> >>>>> If you are running that cmake command from your intended DIVA build >>>>> directory (Which should be empty, do not manually build fletch and kwiver >>>>> to the same target build directory), >>>>> This will execute the 'Superbuild' control flow in the DIVA CMake >>>>> files. >>>>> (A CMake super-build is a project which downloads, configures and >>>>> builds other projects. ) >>>>> >>>>> This control flow from your command should return something like this : >>>>> >>>>> *The C compiler identification is GNU 5.4.0* >>>>> >>>>> *The CXX compiler identification is GNU 5.4.0* >>>>> >>>>> *Check for working C compiler: /usr/bin/cc* >>>>> >>>>> *Check for working C compiler: /usr/bin/cc -- works* >>>>> >>>>> *Detecting C compiler ABI info* >>>>> >>>>> *Detecting C compiler ABI info - done* >>>>> >>>>> *Detecting C compile features* >>>>> >>>>> *Detecting C compile features - done* >>>>> >>>>> *Check for working CXX compiler: /usr/bin/c++* >>>>> >>>>> *Check for working CXX compiler: /usr/bin/c++ -- works* >>>>> >>>>> *Detecting CXX compiler ABI info* >>>>> >>>>> *Detecting CXX compiler ABI info - done* >>>>> >>>>> *Detecting CXX compile features* >>>>> >>>>> *Detecting CXX compile features - done* >>>>> >>>>> *Found Git: /usr/bin/git (found version "2.7.4") * >>>>> >>>>> *I am pulling and building fletch!* >>>>> >>>>> *I am pulling and building kwiver!* >>>>> >>>>> *Configuring done* >>>>> >>>>> This is telling you that it will create a Makefile that will download >>>>> the fletch, kwiver, and kwant source code and build them each, and then >>>>> build the DIVA code base >>>>> >>>>> The Eigen Error mentioned is usually due to running CMake on KWIVER >>>>> source (from with the KWIVER build directory) (Which should be empty and a >>>>> different folder or a subfolder from the DIVA build directory) and not >>>>> providing a fletch_DIR for the KWIVER CMake script to use during it's >>>>> configuration process >>>>> >>>>> Did you successfully build Fletch and KWIVER manually? >>>>> >>>>> If so, you should run CMake for DIVA, from an empty build directory >>>>> like so, to inform the DIVA super build of the location of your KWIVER >>>>> build directory >>>>> >>>>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release -Dkwiver_DIR:PATH= >>>>> >>>>> CMake will return something like this: >>>>> >>>>> >>>>> *Looking for your kwiver...* >>>>> >>>>> *I found your kwiver!* >>>>> *It uses this fletch * >>>>> >>>>> *I am pulling and building kwant!* >>>>> >>>>> *Configuring done* >>>>> >>>>> >>>>> >>>>> I suggest using the cmake gui to help see what directories and CMake >>>>> options are set to help get your build set up >>>>> >>>>> (I recommend checking the 'Grouped' and 'Advanced' options in the GUI) >>>>> >>>>> >>>>> you can get it with >>>>> >>>>> $sudo apt-get install cmake-qt-gui >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> Aaron >>>>> >>>>> >>>>> On Sat, Jan 13, 2018 at 3:01 AM, Ankit Parag Shah >>>> > wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> While building DIVA project using the following steps - >>>>>> https://github.com/Kitware/DIVA, with a fresh Kwiver and fletch >>>>>> installation steps, I am facing errors while performing the following >>>>>> installation step. >>>>>> >>>>>> $ cmake ../../src -DCMAKE_BUILD_TYPE=Release >>>>>> >>>>>> Error is as follows: - >>>>>> >>>>>> CMake Error at /usr/share/cmake-3.5/Modules/F >>>>>> indPackageHandleStandardArgs.cmake:148 (message): >>>>>> Could NOT find Eigen3 (missing: EIGEN3_INCLUDE_DIR >>>>>> EIGEN3_VERSION_OK) >>>>>> (Required is at least version "2.91.0") >>>>>> Call Stack (most recent call first): >>>>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 >>>>>> (_FPHSA_FAILURE_MESSAGE) >>>>>> CMake/FindEigen3.cmake:81 (find_package_handle_standard_args) >>>>>> CMake/kwiver-depends-Eigen.cmake:3 (find_package) >>>>>> CMake/kwiver-depends.cmake:4 (include) >>>>>> CMakeLists.txt:138 (include) >>>>>> >>>>>> Upon researching on Google about the error caused and understanding >>>>>> use of EIGEN, there are various hacks suggested to overcome the problem. >>>>>> The problem seems to be within CMAKE which is not able to find >>>>>> EIGEN3_INCLUDE_DIR in path variable. >>>>>> >>>>>> Currently, I am using cmake 3.5.1, may I ask whether it is >>>>>> recommended to perform hacks or it is better to install latest version of >>>>>> cmake available going forward. >>>>>> >>>>>> Looking forward to your response. >>>>>> >>>>>> Kind Regards, >>>>>> Ankit Shah >>>>>> Masters Student in Language Technologies >>>>>> Carnegie Mellon University. >>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-users mailing list >>>>>> Kwiver-users at public.kitware.com >>>>>> https://public.kitware.com/mailman/listinfo/kwiver-users >>>>>> >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: