[digikam] [Bug 426481] Face recognition feels like a regression from 6.4
https://bugs.kde.org/show_bug.cgi?id=426481 --- Comment #18 from Minh Nghia Duong --- (In reply to Chris from comment #17) > Tried again with latest build of 20201008. > > Reset the faces database in maintenance > waited till it finished rebuilding the faces database > confirmed/ rejected all old existing face suggestions > Ran "recognize faces" again with 90% > - Suggestions was right, but only 4-5 suggestions for some people > > Ran "recognize faces" again with 65% > - Having 1.400 suggestions > - But the rate of right suggestions is only about 20% (even for people with > 1.000 right assigned faces) > > maybe one more suggestion: if "reset face database" is run digikam should > ask if all unconfirmed images should be moved to unknown. as like now I have > 1.100 images with only 20% right suggestions and if I reject them all it > doesn't suggest the right people again after running recognize faces again > as it seems (which is good in normal use, but not if I plan to reset the > database)? Hi Chris, Does the face recognizer get better overtime? Because the new face recognizer is machine learning based so it's need to be train with enough data in order to predict correctly. If it still sucks, can you describe briefly its problems please? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426309] Support face detection back ends that require larger data sets
https://bugs.kde.org/show_bug.cgi?id=426309 --- Comment #11 from Minh Nghia Duong --- Hi all, About different detection models, could you give me the link to some models that you're having in mind? I would like to dig into the different models to see their implementation with opencv in order to prepare for this new module. Thank you in advance. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426888] Digikam crashes shortly after I attempt to start it
https://bugs.kde.org/show_bug.cgi?id=426888 --- Comment #6 from Minh Nghia Duong --- Hi, It crashed in function readNetFromTorch() so the data file for neural net is not found. Can you see the location of neural net files in the debug message while digikam is loading? And is the data files are copied to '/usr/share/digikam/facesengine' or other location where digikam is installed in your system? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426309] Support face detection back ends that require larger data sets
https://bugs.kde.org/show_bug.cgi?id=426309 --- Comment #10 from Minh Nghia Duong --- (In reply to princeanthony.tiago from comment #9) > Just wondering if you'd had any further thoughts on this topic. Given that > the limitations of the current face detection model are basically preventing > me from using the software, I'd be happy to test a branch build (Windows) > when one is ready. Yes, this feature is definately on my TODO list. However, my schedule now is a little stacked but I will works on this feature in the following weaks. I hope to release it with version 7.3. If you have any suggestion about the workflow, how it should look or function, I'm all ear. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #155 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #154) Yes, only one FaceExtractor is allocated at the init sequence of digikam. After that, the multi-threading only envoked in the recognition process. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #153 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #151) > Marcel, > > You lost memory a little bit, but the infamous crash in Preview thread > disappear. Right ? > > If yes, we will trying to discover the source of the problem for this > memory. Next stage for me is to add a new compilation option to use ASAN > tool: > > https://en.wikipedia.org/wiki/AddressSanitizer > > About multithread while face detection, i'm not sure. If i remmeber, Nghia > report to me that multicore support in face detection have been disabled for > performance reasons, as low level API is not re-entrant. > > Perhaps Nghia can provide more details for this point. > > Gilles Hi Gilles, It's not quite what you said. I disabled multiple face extractors in faces engine, which means for now, in faccial recognition, there is only one FaceExtractor being used. This avoid multiple memory allocation for faical recognition. However, with only one FaceExtractor, the facial recognition process still runs multi-threading by using cv::parallel_for_ function. It's implemented in file : https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/facesengine/recognition/opencv-dnn/opencvdnnfacerecognizer.cpp , at lines 465 and 505. If you want to desactivate it for a test run, just replace these line with a normal loop. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426309] Support face detection back ends that require larger data sets
https://bugs.kde.org/show_bug.cgi?id=426309 --- Comment #7 from Minh Nghia Duong --- (In reply to Rob D from comment #6) Hi Rob, I agree with your concern. Normally, for the current CNN models of object detection, the pre-processing and post-processing are nearly the same between different neural network. The only significant differences are the backend type for network importation and the input size of the network. The input size seems easy to configure in user interface but the backend type supported by OpenCV is limited and therefore needs better specialization to avoid errors. About YOLOv4 and v5, it's already out and I tried it on digikam. It requires the latest version of OpenCV and doesn't seem to make a significant change in performance on CPU. Might be it would work better on GPU but the only GPU driver supported by OpenCV is CUDA. Can you describe to me more about the workflow of loading a customized neural network that you have in mind? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426309] Support face detection back ends that require larger data sets
https://bugs.kde.org/show_bug.cgi?id=426309 --- Comment #5 from Minh Nghia Duong --- Hi all, Say that we can support customized face detection backend. How do you intend to use it after importing the data files? For example, how would you like to configure it and the DNN would be another pre-trained model, or do you want to train the model yourself. Could you describe to me more about the use-case scenario of the configuration to make to install a customized model? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #105 from Minh Nghia Duong --- (In reply to Maik Qualmann from comment #104) > This backreace is not from the current head of master. Please try the > current master version. > > Maik This is the new back trace : Thread 86 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff0bfff700 (LWP 16177)] 0x77077a32 in Digikam::PreviewLoadingTask::execute (this=0x8f9f3240) at /home/minhnghiaduong/Documents/Projects/digikam/core/libs/threadimageio/preview/previewtask.cpp:443 443 m_thread->taskHasFinished(); (gdb) bt #0 0x77077a32 in Digikam::PreviewLoadingTask::execute() (this=0x8f9f3240) at /home/minhnghiaduong/Documents/Projects/digikam/core/libs/threadimageio/preview/previewtask.cpp:443 #1 0x7708a0f5 in Digikam::LoadSaveThread::run() (this=0x606f79a0) at /home/minhnghiaduong/Documents/Projects/digikam/core/libs/threadimageio/fileio/loadsavethread.cpp:134 #2 0x770b2fe8 in Digikam::DynamicThread::Private::run() (this=0x7aff5ba0) at /home/minhnghiaduong/Documents/Projects/digikam/core/libs/threads/dynamicthread.cpp:191 #3 0x73eaf2b2 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x73eb217d in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x72cab6db in start_thread (arg=0x7fff0bfff700) at pthread_create.c:463 #6 0x73595a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #103 from Minh Nghia Duong --- Created attachment 131496 --> https://bugs.kde.org/attachment.cgi?id=131496=edit BackTrace after fixing FaceExtractor memory consumtion Hi Maik, Here the backtrace. It's still the same error. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426309] Support face detection back ends that require larger data sets
https://bugs.kde.org/show_bug.cgi?id=426309 --- Comment #4 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #1) > Nghia, > > Look the topic of this entry, this is what we talk together last winter > about the capability to download data model on demand. > > Supporting Yolo model is a good candidate to be hosted somewhere in > digikam.org (for ex), and users can use this model instead SSDMobilenet for > a better detection. > > digiKam will upload data file from Internet, store the file somewhere in > user space, and use it. > > Gilles I will look into it. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #98 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #97) > Marcel, > > See my comment: > > https://bugs.kde.org/show_bug.cgi?id=426185#c4 > > The huge memory allocation at startup is now fixed by Nghia commit: > > https://invent.kde.org/graphics/digikam/-/commit/ > 28027b21d9fa4368eb2f2ad26dbb1cb33e274cce > > It still to check if the OpenCL memory leak from OpenCV is fixed with my > commit: > > https://invent.kde.org/graphics/digikam/commit/ > b5e3c5987a7380fdc5ce9a59ee5e62e6acbaf51b > > And if the another memory glitch is fixed by Maik commit: > > https://invent.kde.org/graphics/digikam/commit/ > 5102e32b4e9e308df760a45624832caa204d82c0 > > I will rebuild AppImage 64 bits this morning. > > Gilles Hi Gilles, Even with this version, the crash during face detection still occurs on my machine Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426185] digiKam starts more slowly than previous versions
https://bugs.kde.org/show_bug.cgi?id=426185 --- Comment #2 from Minh Nghia Duong --- Hi Maik, This issue has been fixed by implementing a shared private static pointer, under commit https://invent.kde.org/graphics/digikam/-/commit/28027b21d9fa4368eb2f2ad26dbb1cb33e274cce Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #92 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #91) > Nghia, > > It still a pending Q in my mind. Currently, all digiKAm bundle still > compiled with OpenCV LTS version 3.4.11. > > There is an advantage to switch definitively to OpenCV 4.x ? > > Gilles I doubt that. I saw that OpenCV 4.x has added recent trending models, but most of the current code base is nearly the same. I already tried it out when I tried YOLOv4 on digiKam since YOLOv4 required OpenCV 4.x. The performance is not much different, in my opinion. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #88 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #86) > Nghia, > > well, this is not what's a read. depending of OpenCV version, especially the > 4.x, opencv try to use GPU optimizations everywhere if possible. > > Perhaps DNN code as well is not optimized, but i'm sure that DNN code call > internal OpenCV API which are optimized, for ex about matrix management. > > My test under Kubuntu VM customized with and without 3D acceleration setting > demonstrate the dysfunction about memory allocation is lost at run time. > > Gilles OpenCV provides GPU optimization for matrix operations but I'm sure that we can actually choose the processing unit for OpenCV::dnn::net via their API. And currently, the only GPU driver supported for OpenCV's neural network is NVIDIA CUDA. By default, all the internal backend of OpenCV::dnn::net are handled by CPU -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #83 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #82) > Hi all, > > Reading the OpenCV document, that i try to understand, we have this > envirronement variable which can be changed at run time: > > OPENCV_OPENCL_DEVICE > > ... as explained here: > > https://docs.opencv.org/2.4/modules/ocl/doc/introduction.html > > ... and if i'm not too wrong, if i set > > export OPENCV_OPENCL_DEVICE=CPU > > this will only use CPU and never GPU optimization internally with OpenCV. > > I'm right ? > > Gilles In my knowledge, currently, OpenCV DNN is using CPU as default. For GPU, there is only NVIDIA CUDA is supported and it's required further configuration. So for now in digikam faces engine, all has been processed on CPU. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #80 from Minh Nghia Duong --- I implement singleton on FacialRecognitionWrapper so that it initiated only once. I also reduce the number of FaceExtractor to 1, which is the same as the previous version of faces engine. However, this error still occurs, and I notice that it only occurs when the Unknown face tab is opened and the cropped faces are rendered. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #72 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #70) > This is a desktop video capture under Kubuntu 20.04 VM session running > compiled digiKam 7.2.0-beta1 while face detection inside valgrind. Look well > the memory allocation with ksysguard. Yes, we allocate memory and clear step > by step. There is not cumulative memory leak visible. > > Of course, using valgrind, this decrease running speed by 20 but the > behaviour is similar than under Mageia7 tested yesterday. > > Nghia, there is no active clustering while faces detection. Right ? > If yes, well it's coherent to see no memory allocated to group similar faces > before recognition processing. > > If the Marcel dysfunction exists, how to reproduce exactly ? Outside the > fact of cumulative model data files loaded at startup that will reduce the > fingerprint at when it will be fixed, i cannot see a memory dysfunction at > face scan. > > Gilles They aren't active but the instances are pre-created along with Workers of FaceManagement. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #69 from Minh Nghia Duong --- (In reply to Maik Qualmann from comment #66) > The main problem is the "shapepredictor.dat", this file is also loaded 40 > times into the memory. > > Maik shapepredictor.dat is loaded with FaceExtractor. Therefore, when we avoid the duplicate of this object, we can reduce the memory consumption. For now, I used 10 FaceExtractor objects to x3 speed of facial recognition. If you like I can reverse it back to use only 1 object. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #65 from Minh Nghia Duong --- Yes, it has to be 4 times but I found only 3 instances in FacesManagement. But either way, the solution to this problem can be making this class a singleton since it is nothing but an interface to the recognition of faces engine. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #63 from Minh Nghia Duong --- (In reply to Maik Qualmann from comment #60) > The cause of the high memory consumption at the beginning in digiKam-7.2.0 > is bug 426185. We load the file > "/usr/share/digikam/facesengine/openface_nn4.small2.v1.t7" into memory 40 > times. > > Maik Hi Maik, I find that we create 3 different FacialRecognitionWrapper instances in FaceManement. Can I change this class into singleton to assure the coherence of faces engine and avoid memory consumtion? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426185] digiKam starts more slowly than previous versions
https://bugs.kde.org/show_bug.cgi?id=426185 --- Comment #1 from Minh Nghia Duong --- (In reply to Maik Qualmann from comment #0) > The file "/usr/share/digikam/facesengine/openface_nn4.small2.v1.t7" is > loaded 10 times per RecognitionPreprocessor. A total of about 40 times at > the start of digiKam. Can't we load the file once and use it multiple times? > > Maik Hi Maik, I am intent to load an array of 10 faces extractor which contain OpenCV DNN Net object in order to accelerate batch processing. These objects can not be copied. However I fail to understand while the DNN Face recognizer is reloaded 4 times before digikam started. Could you explain why the faces management try to reload the face recognizer 4 times, please? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #12 from Minh Nghia Duong --- I will go through this problem while reform faces management in preparation for the portage to DPlugin. I hope I will fund somethings -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #10 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #9) How large is your collection? I found that it crashes after found about 3000 faces. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #8 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #7) > Hi Nghia, > > Do you use also a Ubuntu like Linux ? > Yes, I use Ubuntu 18.4. > Gilles -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426175] Segmentation fault while Faces detection
https://bugs.kde.org/show_bug.cgi?id=426175 --- Comment #6 from Minh Nghia Duong --- Hi Gilles, Yes, I can reproduce it with a huge trunk of images. I am investigating it. I suspect that somewhere in faces pipeline where I changed QImage to QImage* could cause the problem. As I remember, it does not involve face detection, but it might link somewhere. With the backtrace, I think the crash might be during the rendering of cropped faces to Widget. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 --- Comment #8 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #7) Thank Gilles, Is there any conflicts that worth noticing? Best, Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426003] Implementing object detection
https://bugs.kde.org/show_bug.cgi?id=426003 --- Comment #8 from Minh Nghia Duong --- Hi Markd, As Trung said, for now, both the pre-trained YOLO and SSD models can recognize basic objects. In order to apply recognition on a specific set of objects, users might need to find a specific pre-trained model or to train a model that works for them. However, we can prepare a module for general object recognition that can be compatible with YOLO and SSD. User can then install their pre-trained model with some basic configuration that adapts to their usages. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426003] Implementing object detection
https://bugs.kde.org/show_bug.cgi?id=426003 --- Comment #5 from Minh Nghia Duong --- Implementing DNN detection is simple, but we also need to define the use-cases and workflow for object detection. We can just choose an image and then return the image with bounding boxes and the name of the object like the example in the link above, but it's not really pratical for digikam, is it? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426003] Implementing object detection
https://bugs.kde.org/show_bug.cgi?id=426003 --- Comment #3 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #2) Yes, I did. Actually, I tried it and it works wonderfully with the existing SSD and YOLO faces detection of faces engine. All we need to do is to download the corresponding files and add a little code to differentiate the pre-defined classes of the model. If you want I can implement it after the merge of GSoC. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 425981] limit face recognition by tag's,
https://bugs.kde.org/show_bug.cgi?id=425981 --- Comment #2 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #1) > Nghia, > > This new entry in bugzilla can be considerate are solved with the new faces > clustering implementation from your project. > > Best regards > > Gilles I don't know. If this is about wrong recognition, my work would have improved it. If it's about filtering image collection before the recognition process, it more likely belongs to Kartik's work, I think. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409995] Scan for Faces in video files is not yet supported
https://bugs.kde.org/show_bug.cgi?id=409995 Minh Nghia Duong changed: What|Removed |Added CC||minhnghiaduong...@gmail.com --- Comment #3 from Minh Nghia Duong --- Real-time face detection and recognition on video are possible. However, if you wish to extract all the faces appear in the video, it is possible that too many faces are returned, depend on the number of frames. If you wish to return only distinct faces in the video, face clustering is needed. In both ways, video analyse like this, as Gilles said, is time-consuming. But if this feature is still in need, I could try to implement it -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 --- Comment #6 from Minh Nghia Duong --- (In reply to Kartik from comment #5) > Hi Nghia, > > The Top Level Connections for the Deleting button are done in > DigikamItemView. The Delete Button forms part of a FaceRejectionOverlay, and > the signal for pressing the delete button is set here: > https://invent.kde.org/graphics/digikam/-/blob/master/core/app/items/views/ > digikamitemview.cpp#L342. > > The > removeFaces(https://invent.kde.org/graphics/digikam/-/blob/master/core/app/ > items/views/digikamitemview.cpp#L411) method then delegates deletion to a > FacePipeline. I think you might be familiar with FacePipeline functionality. > DatabaseWriter works with the FacePipeline and picks up the package (when > its time for being processed arrives), and then calls the FaceUtils method > for actual removal of the Image-Tag association: > > See this connection for DatabaseWriter with FaceUtils: > https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/ > facemanagement/workers/databasewriter.cpp#L142. > > There's multithreaded implementations that lead to DatabaseWriter picking up > the package sent via FacePipeline, however it isn't necessary to worry about > that in my opinion. > > Kartik Thanks, As I see it, FaceUtils only manage face tag and retrieve identity, and FacePipelineFaceTagsIface doesn't hold the information of the registered face embedding. Therefore in order to delete the face embedding in the database, we have to add an additional association between face item and face embedding. If I do it now, it will add up more conflicts to our projects. Therefore I will find a way to do it after the 2 projects merged. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 Minh Nghia Duong changed: What|Removed |Added CC||minhnghiaduong...@gmail.com --- Comment #4 from Minh Nghia Duong --- (In reply to Kartik from comment #3) > Hi Maik, rebuilding the training database is certainly a good idea to avoid > this error. I wasn't aware that feature existed. > > It's certainly desirable for Faces to remain in the database, if an Image is > deleted. However, if the User presses (x) on a Face, then he does want to > Delete that face (not delete the Image). If the user is implying that this > is not a face, then why is it being used as Training Data? > > Apologies for any inconvenience. > > Kartik Hi Kartik, Yes, I think it should delete the face embedding of a deleted face. Maybe we can add a reference counter to delete the registered identity as well when there isn't any face left? Could you point me to the code of the deleting button so that I can have a better understanding of the workflow here? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416630] Use N nearest neighbor search
https://bugs.kde.org/show_bug.cgi?id=416630 --- Comment #4 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #3) Hi, The K-Nearest search has been implemented and tested. It gives the best result so far. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416988] Objects / Forms / Monuments / Context detection and recognition using Deep Learning
https://bugs.kde.org/show_bug.cgi?id=416988 --- Comment #6 from Minh Nghia Duong --- (In reply to caulier.gilles from comment #5) > Nghia, > > Just look my previous comment #4... > > Gilles Hello Gilles, It's a very interesting feature. What is the name of the model used in the data vector generator? The context extraction from photo might be feasible, but at first, we need to scale the implementation of YOLO detection to accelerate the speed of processing or change to another version of SSD-MobileNet. Because the current version of SSD-Mobile used in digikam is only for face detection and it doesn't work really well. Furthermore, context extraction might envoke a Recurrent neural network, if such a pre-trained model exists for downloading, we can do it. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #25 from Minh Nghia Duong --- (In reply to griffiths_andy from comment #22) > Since the slideshow preferences have moved in 7.0.0-beta3 to within the > slideshow screen itself as part of the progress indicator buttons, it is > observed that the progress indicator setting is not persistent between > slideshow uses, and has to be toggled each time. > > You seem to have already anticipated this, because of course, if it was > persistent then once the progress indicator was switched off it would be > impossible to enter the dialog again without resorting to editing > ~/.config/digikamrc and toggling SlideShowProgressIndicator=true Yes, you are right. If we set to not showing this progress indicator, the only way to switch it back is to modify the config file. > Maybe the settings should be available on a hotkey, so then persistent > settings can be changed when not otherwise visible. Otherwise you have to > exit the slideshow and re-enter before you can change settings. Configure it in a hotkey is doable. However, it could be a little bit confusing for some users, since everyone tends to not looking for a hotkey to solve the problem when the progress indication disappears. Therefore, I am not sure it's a good idea to put it in a hotkey. > I may be missing that the settings are already on a hotkey, and I'd be > grateful to know what that is if so! > > Please consider this change, as changing settings each time to remove the > progress bar is a hump in the process, and a divergence from behaviour in > 7.0.0-beta2 and earlier. How about we do it otherwise, by using a hotkey to hide the progress bar? Then it will never appear again until the hotkey is repressed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #24 from Minh Nghia Duong --- Hello, Yes, sure. I will try -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384444] Wish: support "remote metadata services" (eg. AI based image tagging like Clarifai.com)
https://bugs.kde.org/show_bug.cgi?id=38 --- Comment #6 from Minh Nghia Duong --- Hello Jens, I am not familiar with the Clarifai platform. Could you help me clarify some points, please? Firstly, As in your description, when you import an image to Clarifai, it will return an output with the image tags embedded in metadata of the image itself or just an encoded JSON of tags? And if it's true, is the representation of face tags in metadata is universal to other platforms? And you want a tool to export images to Clarifai or a tool to read the output of clarifai to the images? Nghia. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #18 from Minh Nghia Duong --- Hello, I have completed the plugin slideshow and here is the link to my merge request: https://invent.kde.org/kde/digikam/-/merge_requests/11 Thank you in advance for reviewing it for me. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #16 from Minh Nghia Duong --- I am adding these updating functionalities to setItemInfo of DBInfoIface but one thing a little bit weird appears to me. It is that the method toggleTag of SlideShow is used nowhere. This method only emit a signal to inform digikam and Light table that the tag has changed. Could you help me identify the use of this method, please? If it has no use, can I delete it? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 Minh Nghia Duong changed: What|Removed |Added Attachment #126428|0 |1 is obsolete|| --- Comment #12 from Minh Nghia Duong --- Created attachment 126694 --> https://bugs.kde.org/attachment.cgi?id=126694=edit Replace Utilities/slideshow by dplugin slideshow Hello, I have finished the migration of slideshow to dplugin. The completed patch is in the attached file below. However, I meet a problem to update Metadata of an image from slideshow through the DInfoInterface. I haven't found the method to rewrite the change in Image metadata to the database after each change. I doubt that it exists. Could you take a look at the patch and help me reverify these functionalities? If they haven't existed, can I have permission to add it to the code base of DInfoInterface? Thank you in advance. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #10 from Minh Nghia Duong --- Hello Gilles, I am finalizing it. I will deliver to you the patch tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #7 from Minh Nghia Duong --- Thanks Gilles, It has been clearer to me. Could you point me to the function or the file where the slideshow is initiated from the main interface? Because I have only found codes in app/view/stack where some signals are used to init SlideShowBuilder, and I am not sure if it is where slideshow is really initiated. Nghia. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture [patch]
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #5 from Minh Nghia Duong --- Gilles, Actually Yes, It's still unclear to me how the information is passed between DInfoIterfaces and what is the link of classes SlideShowBuilder and SlideShow except that they use SlideShowSettings in common. Could you give me a guide on the order of execution in the setup and teardown routines of a slideshow, please? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #3 from Minh Nghia Duong --- Thanks Maik, I will try it. Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture
https://bugs.kde.org/show_bug.cgi?id=414055 --- Comment #1 from Minh Nghia Duong --- Created attachment 126428 --> https://bugs.kde.org/attachment.cgi?id=126428=edit Patch for slideshow plugin I have created a copy of slideshow utilities in dplugin for slideshow. It's all compiled and seems normal to me. However, I am dealing with the some problems with DInforInterface and I have not migrated SlideShowBuilder as an interface for slideshow plugin. Could you take a look at the patch and give me some advice, please? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414055] Port Slideshow tool to plugin architecture
https://bugs.kde.org/show_bug.cgi?id=414055 Minh Nghia Duong changed: What|Removed |Added CC||minhnghiaduong...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 414284] Improve Setup/Slideshow View Options Layout
https://bugs.kde.org/show_bug.cgi?id=414284 --- Comment #1 from Minh Nghia Duong --- Hello, Here is the merge request of the patch: https://invent.kde.org/kde/digikam/merge_requests/8 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 392758] Slideshow with random pictures
https://bugs.kde.org/show_bug.cgi?id=392758 --- Comment #9 from Minh Nghia Duong --- Created attachment 124002 --> https://bugs.kde.org/attachment.cgi?id=124002=edit Patch for random slideshow Here is the patch that adds suffle functionality to slideshow. Use can activate this functionality by checking the suffle checkbox in the configuration panel of slideshow. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 392758] Slideshow with random pictures
https://bugs.kde.org/show_bug.cgi?id=392758 --- Comment #7 from Minh Nghia Duong --- Sorry, my bad. I thought it was to assign the job. By the way, I have add an option to show images in random order. The images are suffled at the beginning at each slideshow. Is it ok to you or you need the order of showing images is changed at each image during slideshow? Nghia -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 392758] Slideshow with random pictures
https://bugs.kde.org/show_bug.cgi?id=392758 Minh Nghia Duong changed: What|Removed |Added CC||minhnghiaduong...@gmail.com Assignee|digikam-bugs-n...@kde.org |minhnghiaduong...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
