Category: Team Status Reports

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risks that could jeopardize the success of the project is our color model. The original and quantized color model performs fine on local machines, however the quantized color model performs very poorly on the Jetson. We are still unsure of the specific reason for this since the quantized clothing type and usage models work fine on the Jetson with negligible accuracy losses. We are managing this risk by trying to find the root cause of this issue to make the color model work. If this fails, we will pivot to a new technique which is using the pixel values of the clothing to determine the color. This requires object detection to crop the input photo to just the clothing to prevent extraneous parts of the image affecting the pixel values we evaluate, which has been implemented. The rest of the work just involves predicting a color from the pixel values.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No changes were made.

Provide an updated schedule if changes have occurred.

Our schedule has not changed.

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports. 

List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

Classification Tests

For the classification unit tests, the non-quantized models were evaluated using our validation and sanity check datasets. This was done with 3 different trained models for each classification category(ResNet50, ResNet101, ResNet152) to determine which architecture performed the best. Specific graphs for this are located in Alanis’ individual status report, but the best performing architectures were ResNet50 for all the classification models. The validation datasets are 20% of the total dataset (the other 80% is used for training) and produced a 63% clothing type accuracy, 80% color accuracy, and 84% usage accuracy with the ResNet50. The sanity check dataset, which is made up of 80 images that represent the types of images taken by Style Sprout users(laid/hung/worn on a single color/pattern background, good lighting, centered) produced a 60% clothing type accuracy, 65% color accuracy, and 75% usage accuracy with the ResNet50. 

 

We also ran some other tests to determine how lighting and orientation affect the accuracy of the model. This included determining how image brightness, x and y translations, and rotations affect the model accuracies. Graphs and results are located in Alanis’ individual status report. 

 

The findings from the classification unit tests helped us determine the best model architectures(ResNet50) to use. Additionally, since the accuracies on our sanity check dataset did not meet our use case requirements, we changed our design to include a closet inventory page so users could change any incorrect labels to mitigate the low classification accuracy. 

 

S3 Upload Time Tests

For the S3 upload time tests. We uploaded 80 images to s3 and recorded a timestamp before the upload and took another timestamp after the upload. We took the upload time to be the difference between these two timestamps and the results were overall positive. The upload time was in between 0.15 and 0.40 seconds for the 80 uploads we tested, and the consistency and speed of the upload was welcome news as it allowed us to more reliably ensure our timing requirements for classification. From these test results we determined that no major design changes needed to be made to accommodate S3 image storing.

Database Upload Time Tests

The Database Upload Time was tested much in the same way that the S3 Upload time was tested, by sending 80 images through the protocol and using timestamps to record timings. The results of this test gave an average of 0.09 seconds for database upload, which is well within our use case requirements and doesn’t necessitate a change in our design. There is a slight change between these values and the values I presented. I believe that this is just due to the difference in sending to a server hosted on the same computer and a server hosting on an adjacent computer on the same network. Either way the values fit well within our use case requirements.

Push Button Availability test

Push button availability was tested by pressing the push button 20 times and ensuring that for each of the presses, exactly one image would be taken by the camera. This test passed and we ensured that the pushbutton was successfully integrated into the existing structure. 

 

Jetson Model Accuracy Test

The accuracy of the models were tested on the Jetson with the same dataset that Alanis used as the “sanity check” dataset. On these 80 images we ran the models on the Jetson and got various accuracies and timings. The results we got we in line with the models run by Alanis on her version on tensorflow with the exception of color. We got a type accuracy of 65%,  and a usage accuracy of 67.5%. However, when testing the color on the Jetson using the “sanity check” dataset we got an accuracy of 16.25%. When I did manual testing I believe that it was biased towards colors that the model classified better but when we used a dataset that included a larger selection and more even distribution of colors it became clear that the accuracy for color was very low. This necessitated many attempted changed to the model, using different resnet models, saved_models and other methods but the accuracy either remained untouched or it was unfit for our use cases. 

Because of this issue, we are looking into a pixel based classification algorithm that would find the average color of a piece of clothing and classify it. We hope that with this method our timing is still acceptable and the accuracy is higher. 

We also obtained data relating to the time that it currently takes to classify each article of clothing. This is only one section of the scanning, as we still need to send to s3 and upload to the database but as we saw with the timings above, even with those timings we are below our use case requirement of 3s (average of 1.69s). (I want to mention that there is a small delay in the process not included in these timings, which is a 1.5s delay that displays the picture that the users took and sent. This is to allow the user to correct any errors that might have occurred for the subsequent pictures).

With this timing data, the timing data for s3, and the timing data for uploading it to the database we can get the average time for the total process not including delays for the user to prepare their clothing. And we determined that the average time was 2.03s for the entire process, which is well below our use case requirements of 3s.

Outfit Generation Speed Test (Backend/Frontend integration test)

The outfit generation speed test was done by timing how long it took from pressing “Generate Outfit” to the outfit being displayed on the app. We did 25 trials. The longest amount of time it took for generation was 1.7s and the average was 0.904s, both of these are below our use case requirement of 2s.

Frontend/Backend Tests

We tested the functionality and safety of our settings popup page by ensuring that when users update the setting for how many times a piece of clothing can be used before dirty, and their location setting the new values they provide are validated. Validation is done both on the frontend and the backend for the uses before dirty. Validation for location is only done on the backend, and it works by calling the Open Weather Map API to see if the location exists. If either input is flagged as invalid in the backend, we send an exception to the frontend, which then displays an error message to the user to alert them that their inputs were invalid.  Both inputted fields must be valid for the update to go through.

 

We tested the functionality of our generate outfit page by ensuring that all outfits are generated “correctly”, clicking the generate outfit button causes new outfits to appear, clicking the dislike button updates the disliked outfit table in the database and causes a new outfit to appear, and clicking the select outfit button updates the number of uses for all items in the outfit, updates the user preferences table in the database, and brings the user back to the home page. If an outfit is generated, but there is not enough clothing available to generate one then a message will be displayed to the user that they need to scan in more clothing or do laundry to generate an outfit for this request.

 

A correctly generated outfit is defined below:

• Cold Locations: Includes 1 jacket (if the user has an available jacket). May include a sweater, cardigan, etc (if the user has them available, with some chance). Always has a top/bottom outfit OR one-piece outfit (no shorts or tanks).
• Neutral Locations: Excludes jackets but may include sweaters, cardigans, etc (if the user has them, with some chance). A top/bottom outfit OR one-piece outfit is also always returned.
• Hot Locations: A top/bottom outfit OR one-piece outfit is always returned. No sweaters, jackets, hoodies, etc are ever returned.
• All clothing items generated in outfits must match usage type (casual/formal) and be clean.

 

We tested the functionality of the privacy notice feature by ensuring that users who have not accepted the notice will have it on their page and can only use the app’s features after accepting it. We tested that accepting the notice is saved for the user. We also tested to ensure that an error message pops up to alert the user if they try to bypass the notice without accepting it. 

 

We tested the functionality of the laundry feature by ensuring that selecting the “do laundry” button causes all items to be marked as clean on the database. We also tested that when an outfit is generated and selected, that all items in the outfit have their number of uses increased in the database. If this number is higher than the user set value for “number of uses until dirty” this should update the item to be dirty. We also validated that dirty items are not part of generated outfits.

 

We tested the functionality of our closet inventory page by ensuring that no matter the number of clothing items in the database, at most 6 will appear on each page. We also tested that each clothing item in the database will appear on exactly one of the closet pages. This was done with a 0, 3, 6, 18, and 20 images/entries in the database. We also tested the scrolling functionality by ensuring that users could not scroll before the first page and could not scroll to the next inventory page if there were no more clothes to show. We also tested the popup to change labels by ensuring that if the GET request to get the current labels for an image failed, we would display a relevant error message if we were unable to connect to the backend or if there was an HTTP error in the response form the backend. We did this by making sure that the server was not running so that the frontend could not connect to it and by sending various HTTP error codes instead of the requested labels from the backend to the frontend. We also checked that when the user presses submit after changing the labels, a POST request with the changed labels was sent to the backend and the relevant fields in our database were updated. This was done by changing the labels for different clothes on each page and ensuring that our database was updated with the new labels provided.

 

We tested the user-friendliness of our app by giving 3 people a background on what our app does and how to use it. We then gave them the app and hardware to use Style Sprout and timed how long it took them to use different features. We also had them rate the app out of 10 based on intuitiveness and functionality. We defined intuitiveness as how easy it was to understand the features, and functionality as how easy it was to actually use them.

For the results of these tests, we met our intuitiveness requirements with an average 9/10. Time-wise we also passed the tests, with all features being doable within 10 seconds. However, we did not meet our functionality requirements and got an average of 5/10. Users explained that they struggled specifically with taking images with the camera, and struggled with centering their clothing in the images, leading to a decreased accuracy for classification. As a result, we are adding both a button and a camera stand to our final product to make this process easier for users. After adding these features, we hope to run this test again.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk at the moment is the classification accuracy of images from the camera. We are getting a much lower color classification accuracy from images taken on the camera than our validation and “sanity check” datasets. We haven’t pinpointed the exact reason for this since the clothing type and usage accuracies from the camera are similar to our validation and “sanity check” datasets. We are planning to retrain our color model on a larger dataset, which may require manually labeling more images. If this doesn’t address the accuracy, we may try a different approach which does not require a classification model by trying to determine the most common pixel values in the center of the image to determine the base color of the clothing.

Another issue may be our classification model since the accuracy on the camera is a bit lower than the validation and “sanity check” dataset accuracies for “long” clothing items, like dresses, lounge pants, and trousers. We thought this may have been due to a confusing background that had a doorway and a bright pillow which could have created issues. This confusing background was only used because Riley wasn’t able to find a large enough solid color background at his home over break. However, once we return back to Pittsburgh, we will have one to rerun the tests for “long” clothing items on.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No changes were made.

Provide an updated schedule if changes have occurred.

Our schedule has not changed.

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk that could jeopardize the success of the project is the classification accuracy, same as last week. We are managing this risk by retraining our models, which have achieved higher accuracy than we were getting before. We are also managing this risk by working with a “default” model on the Jetson which has a low accuracy. By using this, we can continue to develop our code on the Jetson and integrate all parts of our system without being slowed down. Later, we will be able to switch out the default model with our actual models. 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

If we have time at the end of our project, we will add functionality to our system that allows the user to change incorrect labels. This will be an additional page which will show all scanned and classified items which have not yet been verified. If the user wants to, they can go through this page and update any incorrect classifications and confirm correct classifications. After pieces are confirmed, they will be removed from the page. Also, even if users do not confirm or change the classification labels of pieces, they will still be in our database of the user’s closet so this feature is optional to use.

We also added a push button to the design, to limit the amount of pictures that will be taken and ensure that the user has the clothing ready and prepared when the picture is taken. The costs are minimal (15$) and will not dramatically change the architecture.

Provide an updated schedule if changes have occurred.

Our schedule has not changed. 

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risks that could jeopardize the success of the project is the accuracy of our models. We are retraining them for reasons discussed in detail in Alanis’ individual status report. These risks are being managed by retraining, but we have also established the contingency plan of having the user confirm our classifications. This would mitigate insufficiently accurate classifications by allowing the user to switch incorrect classifications, ensuring the accuracy of our outfit generation.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No changes were made to the existing design of the system. Changes will be made to our backend/frontend to allow users to confirm the classification if we cannot achieve sufficient classification accuracy.

Provide an updated schedule if changes have occurred.

Our schedule has not changed. 

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

A risk that we have is the transmission of data from the Jetson to the server. Currently, when set up in the computer labs, the Jetson is connected to CMU Device and thus has no issues communicating. However, during presentations this will no longer be the case and the Jetson will be isolated. It could then become an issue to send classification data and images to the server to update on the frontend and database. We are considering a couple different solutions, usb/ethernet cables to connect to the server, hotspotting or simply connecting to CMU Secure if that is possible. We plan to test out some of these solutions next week to see if our embedded device can communicate without being plugged in and connected with CMU Device. 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

Yes, we decided against using AWS S3 for storing our images. This change was necessary because the pricing on S3 is variable to the amount of storage you use, so it became complicated for us to use our Capstone fund on it. We will be using one of our computers as the server for our images instead. This is slightly inconvenient as we will need the storage for the images, but should not cause any issues. Moving forward, if the amount of images and storage needed is more than we have available on our computers, we will look into different places to store them and revisit the pricing for storing images on S3.

Provide an updated schedule if changes have occurred.

Our schedule has not changed. 

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

Status Report 4

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk at the moment is our clothing classification. We are managing this risk by developing a new way to classify clothing, using three different trained models. This should help us get the accuracy we need as each model will be able to focus on one aspect of the item. One model will classify usage, another will classify item type, and the third will classify color. If we are not able to achieve our design requirement classification accuracy, our contingency plan is to have the user confirm that the detected classifications are correct. If they are not, we will allow the user to correct them.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

Yes, we updated the plan for our outfit generation algorithm to take into account the user’s preferences in addition to the clothing they have. This change is necessary because we want the outfits we generate to make sense for the occasion, and the user’s style. This change means that we will need to add a new table in our database, but it should not cause issues time-wise as we already allocated time to update our outfit generation algorithm. Going forward, we will make sure to complete the changes to our outfit generation algorithm for using preferences in the time we have set aside.

We also updated the way that we are classifying clothing. We will be using 3 models instead of one. This change was necessary because we were not getting the accuracy levels for classification that we wanted with our previous design. This change will not affect our latency requirement or our Jetson storage requirement since 3 individual ResNet50s are smaller in size than the original model we had and running classification on a ResNet50 on a lower-spec model of the Jetson takes around 1 second, meaning classifying 3 times will take around 3 seconds. This is discussed in more detail in our design report. Moving forward, we will not move our application to be hosted on the Jetson so that the device can use all its power and have enough storage for the three models.

Provide an updated schedule if changes have occurred.

Our schedule has not changed.

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

Additional Question:

Part A: Written By Alanis

Our product solution will encourage people not to purchase fast fashion products by recommending stylish and weather/occasion-appropriate outfits that already exist in their own closets. Style Sprout allows users to make the most of their existing wardrobe. While this makes getting dressed in the morning easier, it also reduces the need to purchase new, fast-fashion items, minimizing textile waste and resource consumption. As mentioned in part C, the environmental benefits of discouraging people from fast fashion help the globe as the earth’s health and global warming affect everyone. Furthermore, fast fashion companies often exploit workers all around the world since producing cheap clothing can mean underpaying your workers or unsafe factory conditions. Fast fashion leads to many unethical labor practices, as mentioned in this article. Style Sprout encourages users to confidently reuse and style their current clothes, and this push away from fast fashion will also remove support for unethical fast fashion companies who exploit workers in countries all over the world, like Bangladesh, India, and China.

Part B: Written by Riley

Our product solution touches upon many cultural factors due to clothing and attire being an insoluble fragment of culture. Clothing is deeply tied to the representation of culture, tradition, and identity,  making it necessary for us to consider how our solution might affect these factors. Another intractable truth is that clothing is also inherently personal. It is near impossible for an algorithm to summarize and tailor suggestions to all users’ unique styles. As such our solution attempts to touch upon this point by disregarding style as a parameter. Predictions will first only be given with combinations that include covering for the chest and the legs, but will not distinguish between styles outside basic color matching. As such we intend to allow users to maintain their individuality and allow them to express themselves in their cultural values. Only after the user selects clothing would we attempt to partially include their previous selections into future recommendations.

Another cultural implication of our project solution is the western clothing bias inherent in our system. Even if we disregard our personal biases, the types of clothing included, the valid color schemes we include, along with what is classified as “formal”, and “casual” are all rooted in Western (specifically American) culture. As such it is important for us to take this into account for our solution that it is not emblematic of all cultures and all peoples but inherently limited in its usability for certain peoples. This is an issue that is not easily solvable without a massive undertaking but nonetheless is vitally important to consider and disclaim.

Part C: Written by Gabriella

Our product solution addresses the environmental impact of fast fashion. Fast fashion is hugely detrimental to the environment as it leads to increased waste and over consumption. Style Sprout encourages users to make better use of their existing wardrobe, reducing the need for people to purchase new clothing. Through wardrobe management and outfit generation, our app aims to help users make a more intentional use of their wardrobe.

We also hope to help decrease the pressure to participate in fast fashion trends by generating stylish outfits for our users that align both with convenience and environmental consciousness.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk that could jeopardize the success of the project is our ability to determine the usage of a piece of clothing(formal, casual, business casual). Our own model & the pretrained ResNet model both struggle to classify the usage and we believe this is due to the usage being less correlated with the image data (array of pixel values) and more determined by societal standards. This is discussed more in Alanis’ section. We have defined two possible ways of managing this risk—we thought about reverse google image searching the image and webscraping the formality, or, classifying the usage ourselves (with a low accuracy) and then having the user confirm. We are leaning towards having the user confirm but will concretely pick one of the solutions after discussing with an advisor on Monday.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We will have changes to our block diagram and system specification once we pick one of the two alternative approaches defined in the section above. Since we will probably end up having the user confirm the usage type, our use-case requirements will likely lower for the usage classification accuracy and we will add some type of UI to allow the user to confirm/edit the usage type to our frontend, but everything else will stay the same.

Provide an updated schedule if changes have occurred.

Our schedule has not changed. 

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

One of the most significant risks that we have identified is the model classification accuracy. Our initial model accuracy that was achieved from a basic image classification neural network structure and no training data manipulation, was about 40%. We are going to augment our dataset by applying rotations, translations, and flipping. We are also going to fine tune our neural network structure to be applicable to our application. If this does not give us a sufficient accuracy, we will use a pretrained model like Resnet50, which we believe is the best option due to its high accuracy and smaller size than other pretrained models like Resnet101. It is also available with Tensorflow, which we are using.

Another risk we identified is storing the images in our database as originally planned. Based on research, it seems like this would not work well because it can lead to a very increased database size and performance issues. This risk is being managed by saving image paths in the database instead, and having the actual images saved on AWS S3. S3 seems to be ideal for our use case because of its scalability, availability and performance, but if this does not work out, we will look into other file storage systems.

 As for the hardware side of things, there are no significant risks as the modules and desired functionalities are possible on the Xavier NX. One moderate risk is that the processing speed and RAM capabilities would be too low to properly use the model and potentially host the mobile app. We believe that with the proper optimizations, it should be possible, but one thing that we are doing to mitigate this potential issue is by hosting the mobile app on a server if the speed requirements cannot be met on the Xavier.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

Because of the risk with storing images in our database, we decided to use the managing plan and are now going to be using AWS S3 to store our images. It will cost $0.023 per GB per month. We aren’t sure how many GB we will need yet, but the overall price should be minimal. Additionally, this change requires moving a few things around in our Gantt chart to have time to integrate AWS S3 to our application.

We changed our image classification accuracy requirements based on our dataset changes. We are now classifying images by clothing type, color, and usage(casual, formal) since these are labels present in the dataset. We want an 80% accuracy for clothing type and color since this will allow us to generate a majority of accurate outfits while giving us a margin of error for sweater vs sweatshirt. We want 70% accuracy for usage type since this is just meant to be something to help us determine the formality of a piece of clothing, we are still focusing on creating predefined outfits and basing formality off of those.

No hardware changes have been made, some aspects were solidified further, such as the Xavier NX and development environment to be used (Ubuntu 22.04)

Provide an updated schedule if changes have occurred.

Alanis has switched the order of two tasks: model training and predefined outfits. The model classification is a much more difficult task and has the possibility of taking longer than the initial week we had outlined, while creating predefined outfits is not a difficult task and time-consuming but not a main priority right now. Our updated Gantt chart is located here.

This is also the place to put some photos of your progress or to brag about a component you got working.

Photos of our progress are located in our individual status reports.

Part A: Written by Alanis

Our product solution is a solution for a problem which doesn’t really fall into the category of public health, safety, or welfare. Style Sprout, solves a “first world problem”, since it provides outfit recommendations with people’s closets, and finding a good outfit in the morning doesn’t significantly impact your physiological/psychological wellbeing, protect you from physical harm, or provision basic needs for you. There are two ways in which Style Sprout minimally relates to public health. Style Sprout shows users various stylish outfits that already exist in their closet. This is done with the intentions of dissuading people form purchasing cheap fast fashion by reminding them about the great clothes they already have. This benefits public health as fast fashion contributes to global warming and pollution, which harms public health. Style Sprout also notifies first-time users about the way in which we use their data, where we will take pictures of their clothing from a camera feed and input them into a machine learning model, which classifies them. One image of their clothing will be stored in our dataset. This notification ensures that users are aware exactly how we use their data in conjunction with artificial intelligence, which could benefit the psychological health of people who are sensitive to the way their personal data is used. We have ensured that our solution does not harm their safety since the Jetson Nano is a small and widely used computer which would not cause them physical harm, just like the camera and light attached to it. We have ensured out solution will not harm people’s basic needs since it does not relate to food, water, shelter, etc. at all.

Part B: Written by Riley

There is a distinct social need for aid in dressing and fashion. Many people wish to dress better or more appropriately and do not have the capabilities or time. Our product solution can address this need by providing an easier way to achieve this with clothing specific to their closet. Most products currently do not provide an easy way to categorize clothing and require uploading of images, something that could form a technological barrier for some. Our design would allow the users to scan in their clothing quicker than alternatives, making it pertinent for users with minimal time due to caretaking. 

Another social issue that our product solution could help alleviate is socioeconomic. By focusing on the user’s own closet, it allows them to make more out of their closet than what would otherwise have been possible. This is critical for many families by allowing them to limit their clothing bills which is a large portion of many budgets. By generating outfits whether they be typical or novel, it allows the user to gain inspiration in styling and use of previously underused clothing. By allowing the user to make better use of all their clothing, it limits the desire to expand their wardrobe by providing novel options out of existing pieces. Additionally, by better utilizing their clothing, it spreads wear and tear out among many pieces of clothing, limiting damage, easing repairs and generally extending the lifespan of clothing.

Part C: Written by Gabriella

Our product solution, Style Sprout is designed to help users make full use of their existing closets. This reduces their unnecessary clothing purchases and also encourages fashion sustainability. By simplifying the process of choosing an outfit, our solution helps to combat fast fashion which has terrible economic effects. Additionally, as our application helps to prevent consumers from making unnecessary purchases, not only do our users save money but also the more people use it, the lower the demand for fast fashion becomes.

Economically, Style Sprout helps to make both individual and global impact. For individual users, people benefit by reducing their need to purchase new clothing and it also helps them really get full usage out of pieces they already own. More largely, our app helps to decrease the need for fast fashion overall which can lead to less wasteful consumption of clothing. Finally, our product itself does not create a large economic strain as it uses a camera, cloud storage, and a server. Therefore, Style Sprout helps users be more economically conscious and promotes economic sustainability to individual users, as well as it encourages more mindful fashion consumption overall.

• What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

One of the most significant risks that we have identified is the integration of all the separate parts of our project. We think that integrating our classification to be stored in a database which our backend can pull from will be difficult considering all the moving parts. We are managing this risk by setting early deadlines for our individual pieces so that we have a lot of time to integrate. The contingency plan for us not being able to integrate in time would be to simplify our project to make integration easier. 

Another significant risk has to do with the clothing classification for our project. Currently, the dataset we are using is displaying -1s for all of the attributes. We are managing this risk by troubleshooting with the file, however if this does not work as a contingency plan we will look into using alternative datasets that still classify clothing based on item, fabric, and color.

• Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We are going to lower the requirements that we created for classification accuracy, because they were set very high and according to faculty feedback, are too high to be feasible. Instead of the 98% clothing type accuracy, 100% color accuracy, and 85% fabric accuracy, we’ll be looking for 90%, 95%, and 80% respectively. Since our classification requirements have been changed to lower the accuracy we are looking for, we will also lower our requirement for outfit correctness to 80% from 90%. This is because item classification accuracy plays a large part in outfit correctness, so we must lower both accuracy/correctness thresholds. Additionally, we have started to finalize our hardware decisions and have narrowed it down to a few suitable choices for each part.

• Provide an updated schedule if changes have occurred.

The github setup task was reassigned from Alanis to Riley. Aside from this, the web app mockup task was changed to making the demo Flutter app, and the mockup task is now moved to being done with the UI animation task. We are currently on track with our scheduled tasks and assignments. 

Here is the updated schedule.

• This is also the place to put some photos of your progress or to brag about a component you got working.

 

Photos of our progress are located in our individual status reports.