dd@afe456179096:/opt/deepdetect/build/main$ ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/lib:
/usr/lib:
I'm using my own start-up script by the way.. ahhh
deepdetect:
image: jolibrain/deepdetect_cpu
command: bash -c 'LD_LIBRARY_PATH=/opt/deepdetect/build/lib/; export LD_LIBRARY_PATH; ./dede -host 0.0.0.0 & sleep 3; /init.sh; wait;'
container_name: tss_dd
volumes:
# Curl doesnt exist there and we arent root :(
- ./deepdetect/curl:/usr/bin/curl
- ./deepdetect/init.sh:/init.sh
- ./deepdetect/models:/models
- ./deepdetect/models-classifier:/models-classifier
- ./deepdetect/models-tag-classifier:/models-tag-classifier
expose:
- 8080
networks:
- tssnet
restart: always
I added that LD_LIB_PATH config stuff just now - and everything is fine, without it - it wont start
My
init.sh creates a few services from within the container, but thinking about it, I dont need to run that from inside the container.... could be my weird brain at work
by any chance is this the commit that
it's the one i was hoping for :sweat_smile:
ci-master is missing? jolibrain/deepdetect@b85d79eit's the one i was hoping for :sweat_smile:
just testing v0.13.0 release (i built a docker image locally) - ran into the error I described in #1151
I don't believe I had that error in v0.12.0 (or even some of the
I don't believe I had that error in v0.12.0 (or even some of the
ci-master builds between v0.12.0 and now), so I'm guessing something was introduced, or changed in the NCNN master branch upstream?
Yeah so see the updated issue, the missing patch is not enough, there's something else in the way, that will require deeper debug.
As a side note that caffe OCR models cannot be converted to TRT. We failed for a long time and eventually gave up. OCR is scheduled for the torch backend in the coming weeks. This does not fully relate to the current issue, but thought it'd be worth mentionning.
thanks for the heads up about caffe OCR on TRT, that's good to know.
as i'm sure you're aware, OCR is definitely one of the slower models at the moment, so anything that can improve that would be awesome on my end :grinning:
It's slow because of the lstm. It'd be faster in torch and TRT. Nevertheless it's on my R&D task list to look at vision transformer for OCR.
Hey guys!
Quick question about detection using libtorch, I know it is not supported yet? Do you plan to make it available pretty soon?
I know that how it is managed i pytorch is pretty awful (type of input and type of output vary from a model to another, etc.) but it would be nice to have something available in DeepDetect, maybe have a custom input / output format for those models
Quick question about detection using libtorch, I know it is not supported yet? Do you plan to make it available pretty soon?
I know that how it is managed i pytorch is pretty awful (type of input and type of output vary from a model to another, etc.) but it would be nice to have something available in DeepDetect, maybe have a custom input / output format for those models
salut, deformable DETR is on the agenda but that R&D. Basically what runs well with caffe will not be reimplemented shortly as we don't see any reason in our own work. These models basically run CUDNN and transfer to TRT and NCNN nicely. In libtorch we'll implement the nextgen of object detection and we've already started with image classification as ViT and realformer are already within DD.
For simsearch service I got that I can clear indexed images using
curl -X DELETE "http://localhost:8080/services/simsearch?clear=index"
but is there any way I can remove single image after indexing and building for thousands of images?
P.S.: Indexing performed through urls and not with the physical images, so to remove the image from directory option is not avail I guess
@Bhavik_samcom_gitlab hi, this is a good question, we should make the answer clearer, here: basically the similarity search indexes don't really support removal, that's a per design/maths issue. Though FAISS kinda does, cf https://github.com/facebookresearch/faiss/wiki/Special-operations-on-indexes#removing-elements-from-an-index But in practice it is very inefficient. For this purpose DD has no direct support for it.
However, the way of doing this properly is to store a list of removed elements within your application, and filter them out from the results. Once you have too many to remove, rebuild the index instead.
In the future we may support FAISS
However, the way of doing this properly is to store a list of removed elements within your application, and filter them out from the results. Once you have too many to remove, rebuild the index instead.
In the future we may support FAISS
remove_ids but it is so inefficient and dangerous that it may not even happen since it's much cleaner to rebuild the index after a while.
I've already tried it ^^
#22 1602. CXX src/caffe/layers/lstm_layer.cpp
#22 1607. CXX src/caffe/layers/permute_layer.cpp
#22 1608. CXX src/caffe/layers/deconv_layer.cpp
#22 1612. CXX src/caffe/layers/recurrent_layer.cpp
#22 1613. CXX src/caffe/layers/base_conv_layer.cpp
#22 1615. CXX src/caffe/layers/tanh_layer.cpp
#22 1615. CXX src/caffe/layers/detection_output_layer.cpp
#22 1616. CXX src/caffe/layers/exp_layer.cpp
#22 1621. CXX src/caffe/layers/softmax_loss_layer.cpp
#22 1621. CXX src/caffe/layers/dense_image_data_layer.cpp
#22 1621. NVCC src/caffe/util/im2col.cu
#22 1621. Makefile:624: recipe for target '.build_release/cuda/src/caffe/util/im2col.o' failed
#22 1621. nvcc fatal : Unsupported gpu architecture 'compute_86'
#22 1621. make[3]: *** [.build_release/cuda/src/caffe/util/im2col.o] Error 1
#22 1621. make[3]: *** Waiting for unfinished jobs....
#22 1642. src/caffe/layers/detection_output_layer.cpp: In member function 'void caffe::DetectionOutputLayer<Dtype>::Forward_cpu(const std::vector<caffe::Blob<Dtype>*>&, const std::vector<caffe::Blob<Dtype>*>&) [with Dtype = float]':
#22 1642. src/caffe/layers/detection_output_layer.cpp:348:10: warning: 'toplogit_data' may be used uninitialized in this function [-Wmaybe-uninitialized]
#22 1642. Dtype* toplogit_data;
quick question - how does deepdetect utilize multiple gpus if a service is created with
'gpuid': -1 or 'gpuid': [0, 1, 2]? in the API docs it seems to indicate it'll 'select among multiple GPUs' but are the multiple gpus utilized as a single large block of GPU memory, or randomly selected, or some other strategy? (I understand this may differ depending on the backend lib in use, and it seems like only caffe, torch, caffe2 support gpuid
or is the multiple gpuid really only used during training, and not inference?
we're opened to suggestions regarding most useful options
Is there any way to pass the additional parameters with simsearch - indexing, like below
"data":[
"id": "<image_url>",
["id", "category", "<image_url>"]
...
]
I want to perform search of specific category, so these way it get simplified, but unable to figure out the way to do so. can you please guide here the possible ways as well?
Hi @beniz Thanks for demonstrating the vision.
I understand, is there not even an option to store just a simple id that will be associated with the image (without other metadata)? I am asking because the only thing returned is an image url which is not necessarily unique or a key I can use in my database for querying.
I understand, is there not even an option to store just a simple id that will be associated with the image (without other metadata)? I am asking because the only thing returned is an image url which is not necessarily unique or a key I can use in my database for querying.
You can keep a matching table outside of DD between URLs and you internal identifier.