Google Cloud Vision API offers yet another feature- Facial Detection in an image. Not only the location of the face in the image, but also the emotion of the person in terms of four expressions- joy, sorrow, anger and surprise.
Emotions in the image can be really important when a person is uploading his image as their profile picture for professional purposes.
Hence, I would implement this feature to implement Emotion Detection with the use case that if the person uploads his profile picture with no happy expressions, he would be notified of his expressions, and would be requested to change the image to a happy one.
In short, try to make sure that the person is happy in their profile pictures.
Remaining Tasks
Develop the patch for this issue.
(This is one of the tasks of my GSOC 2016 project.)
| Comment | File | Size | Author |
|---|---|---|---|
| #41 | interdiff-38-41.txt | 11.58 KB | ajalan065 |
| #41 | Base-class-for-test-functions-2759031-8-41.patch | 9.08 KB | ajalan065 |
| #38 | interdiff-31-38.txt | 4.38 KB | ajalan065 |
| #38 | Property-added-and-variables-changed-2759031-8-38.patch | 8.55 KB | ajalan065 |
| #31 | Test-for-emotion-detection-2759031-8-31.patch | 8.1 KB | ajalan065 |
Comments
Comment #2
ajalan065 commentedComment #3
ajalan065 commentedI had tried to put the detection feature on the user profile pictures.
However, the control is not validating the line
and skipping the if statement.
Also, the line
does not work.
Where did I do wrong? Please review.
Comment #4
penyaskito$user is not an object. Please pass the entity as an argument.
Comment #5
ajalan065 commentedPassed the entity as the argument to the function.
But still the code does not execute.
I tried a lot debugging it, but could not. I am not able to get where is the code breaking.
Please guide me.
Comment #6
ajalan065 commentedA point regarding the above patch.
Its not that the patch does not work at all.
The drupal message regarding the emotion appears when the user clicks on 'Create Account' button.
Comment #7
eugene.ilyin commentedIt works for me and I see the message "You seem to be unhappy".
What I think:
1. Better to check the image and show the warning only if the file was changed. So, I propose to add the setting for the field and execute this checking when the file will be updated. It can help to reduce the count of requests to Google API.
2. I'm not sure that text of the warning message is good. Maybe should we add proposition, like - please upload a photo where you are smiling and happy?
3. It's just warning but not the validation. So, I think that we should check that current request executed through web but not through cli. Because this warning doesn't make sense for the case with cli.
What do you think about my remarks?
Comment #8
ajalan065 commented@eugene.ilyin,
I could not understand what you want to state by point 1. Can you please clarify it?
In point 3, if we add it as a constraint and validate it, then it might be pretty annoying for the user who is registering; as in that case, it would be a compulsion to be happy on their profile pictures. I have developed the patch on constraints also. So, if you still convinced that we should put it as a constraint, then I will post it.
Comment #9
eugene.ilyin commentedI propose to check not the user entity but file entity. To be able to check is face happy or no for any field. Could you add the setting for this option like with safe search?
No, let's leave it just as the warning. But if the developer/user will do the mass import of entities through feeds for example, better to do not check images if they are imported through CLI. If it will be the case with WEB, so seems we cannot handle it correctly and let's don't worry about it.
Do you understand what I mean?
Comment #10
ajalan065 commentedSo, you mean that face detection should be implemented exactly the same way as the safe search?
And the site administrator would have the control to keep the face detection check at any image field and not only the user picture?
Did I get your point correctly?
Comment #11
eugene.ilyin commentedYes, I think it's more flexible and preferable. Not good to have it by default. Do you agree with me?
Comment #12
ajalan065 commentedYa. That may be better to have it an option. I would post the patch by today.
Comment #13
ajalan065 commented@eugene.ilyin,
I tried to work that out. But the problem is checking the file entity would not be of any good, I believe. Because, the option of Emotion Detection is present on the image fields and not the Image file entity.
So, shall I continue with putting the check on user entity itself? I have added the option to the image fields, thus reducing the API requests.
Comment #14
eugene.ilyin commentedOnly if you will enable it. It's configuration. I think it's nice when you can enable or disable something. It's flexible. What the problem?
Comment #15
ajalan065 commentedYa, I understood that it will work only when it is enabled. That has been done.
However, the configuration is a part of image field, just as the Safe search, and not the file entity (like Enable Google Vision configuration).
So, if we check the file entity, we would not be able to get the field and its definitions for the particular image field.
What I believe is, instead of checking the file, we should fetch the value from the image field, which requires the checking of user/node entities, just as we had done in safe search.
Here lies the problem of checking the file entity.
But, if we check the user entity, we can easily solve the problem.
Another approach may be the use of constraints and validators just as we had done for safe search. If we apply constraints, there is no need to check any entity. The constraint may directly be applied to the fields.
So, what you suggest? Use of constraints? Or checking the user entities?
Comment #16
ajalan065 commentedMoreover, there is not much use of emotion detection, except in the profile pictures. This is just my thinking :)
Comment #17
ajalan065 commentedHere is the patch which works as suggested in #7.
It provides a configuration to not only user entities but to all the image fields as suggested.
It works in similar way as the safe search constraint works, however, with a difference.
Unlike the safe search which puts a constraint on the fields, it just gives a message if the emotion violates the constraint. The emotion is not put as a binding constraint, as it can be pretty annoying in case of creation of new accounts(#8).
Hope this solves our purpose :)
Comment #20
ajalan065 commentedThe test for safe search constraint validation fails, which I suppose is not so important here.
Hence, setting it back to "Needs Review"
Comment #21
ajalan065 commentedHere is the patch with updated schema. The tests passes now.
Please review it and suggest if any changes required. Else we can move to build the tests for it.
Comment #23
eugene.ilyin commentedNo bad, but there is a bug. If you will remove the existing image, the validation will be executed and you will see warning message.
But you should not check the image when you are removing it.
Comment #24
ajalan065 commentedThe bug arises due to the use of drupal_set_message(). Instead, if we use the addViolation(), the bug is removed.
So do you suggest the use of addViolation()? In that case, it would be a compulsion to provide happy image if the configuration is on.
Comment #25
eugene.ilyin commentedI'm not sure but I think that root of the bug is that when we remove the file from the field, you are checking it. It's incorrect behavior in our case. Is there a way to detect when you are removing but not uploading the file?
Comment #26
ajalan065 commentedAs per me, I think that the request is made whenever any file operation is done, because both the conditions of target_id!=NULL and the file uri matches, whenever a file is uploaded or removed.
I have checked it with addViolation(). Everything works as expected.
I have not been able to come up with another way though up till now.
Comment #27
ajalan065 commentedI am unable to find how to check this. Need help!!
Comment #28
ajalan065 commentedThe only way I found to avoid the bug.
Comment #29
eugene.ilyin commentedIt's a wrong way.
I guess that you can try to check here
$data->parent->entity->values['user_picture']['x-default'][0]
let me know does it help or not?
Comment #30
ajalan065 commentedHi eugene.ilyin,
Unfortunately, $data->parent->entity->values['user_picture']['x-default'][0] does not work :(
Can you provide with some other idea?
I am also trying to find out a way, but have not been able to till now.
Comment #31
ajalan065 commentedHere is the test for the patch #21
Please review :)
Comment #32
eugene.ilyin commentedTests are good, but what about solving the problem which I've described? Do you mean that you don't know how to solve it?
Comment #33
ajalan065 commentedI am trying to find the solution to the above bug you had mentioned. But not able to find it yet. Just to keep the work moving, I developed the tests, as they are irrespective of the constraint validator.
Naveen had said he would look into it.
Comment #34
eugene.ilyin commentedOkay, let's wait for his opinion.
Comment #35
naveenvalechahere's quick overview I'll test the functionality manually of this patch later by monday.
This should be
@var \Drupal\user\UserInterface
Instead of loading entityTypeManager multiple times.
Add a new protected property $entityTypeManger and pass its value in setup function.
In Setup() it would be like
$this->entityTypeManger = \Drupal::entityTypeManger();
use single quotes and move the variable out of double quotes.
change $user_name to $username
Comment #36
naveenvalechacorrecting issue status.
@arpit,
any update on this ?
Comment #37
ajalan065 commentedHi naveenvalecha,
I will post the new patch by EOD in accordance to #35.
However, I am still stuck with the comment #27. Need help on that.
Comment #38
ajalan065 commentedHere is the patch following the suggestions of #35 by naveenvalecha. Assigning him the issue for review.
However, #27 still remains unsolved. Need your help here to solve this.
Please review :)
Comment #39
naveenvalechaThis is better than calling static method
$this->container->->get('entity_type.manager');
We should create a abstract parent class and move this function to it.
Comment #40
naveenvalechaAssigning to eugene to help you with #27
Comment #41
ajalan065 commentedHere is the patch following the suggestions in #39.
Please review :)
Comment #42
naveenvalechalooks good
Comment #44
naveenvalechaPatch committed and pushed to 8.x-1.x
Do file a followup for #27 and collaborate with Eugene about the same.
Comment #45
eugene.ilyin commented@Ajalan, please create a separate issue and describe the problem. We cannot just close it and forget about the problem.
Comment #46
naveenvalechaFiled a followup for the same https://www.drupal.org/node/2783941
Closing this one.
Thanks Eugene! for your concerns.