matthewnau / botross Goto Github PK

Feature Outline:

Implement command line functionality to improve ease-of-use for the package. Allows users to quickly update render settings without having to make any code changes.

Required Arguments:

• -i: image path (e.g. "/users/johndoe/original-thumbnail.png")
• -p: profile-image path (e.g. "/users/johndoe/linustechtips.jpg")
• -pf: platform-name (e.g. "youtube")
• -u: uploader-name (e.g. "Linus Tech Tips")

Optional Arguments:

• -o: set the output path (e.g. "/users/johndoe/output-thumbnail.png")
• -bg: background-image path (e.g. "/users/johndoe/background.png") (will use value of -i if not set) (also accepts valid CSS background property values as input)
• -br: set the embedded thumbnail's border-radius (values between 0 and 1rem)

Optional Flags:

• --square: embedded thumbnail's shape will be square
• --small-round-corners: embedded thumbnail's corners will use a smaller border-radius (preset version of -br)
• --no-round-corners: embedded thumbnail's corners will have no border-radius applied
• --no-blur-background: background will have no blur effect applied
• --skip-image-validation: skips output image validation (may lead to occasional rendering defects) (may be necessary when using -bg for custom backgrounds)

Feature Outline:

Define an optional argument that allows users to crop their source image by a specified amount of pixels. This crop would work from the outside-in and apply to all 4 sides of the image.

This option should be non-destructive and only factor in as an additional step in the rendering process, therefore leaving the original image untouched. Should the user find the output unsatisfactory, they can then run the operation again with a different value without having to reacquire the source image.

Argument Syntax Example:

-crop 15 (value is set in pixels)

Additional Notes:

• Consider allowing the user to crop only specific sides (left, right, top, bottom)
• Consider allowing the user to crop each side a different amount (e.g. -crop-left 10 -crop-right 15 -crop-top 5)
• Consider how inheritance of cropping factors in. If a user specified a default -crop 15 and a -crop-left 10 would all sides be cropped by 15px except for the left which would then be cropped by 10px?

Feature Outline:

Develop a simple GUI application that allows users to open an image and draw a box over a certain section. Allow the users to load a specified image and then perform a click-and-drag operation where they can "draw" a rectangular box around a cluster of pixels. (Similar to how the "preview" app in MacOS works in regards to cropping)

Once the user has drawn their box, the application would then display the bounds that specific image slice. This return value would be a list of 4 coordinates/bounds that pertain to the pixel location of where the slice starts and stops.

Why is this useful?

When defining output-image validation methods, the typical approach consists of taking an image slice and then performing some form of analysis on it to determine whether it was rendered correctly. But in order to "slice" the image into different pieces, you need to provide the bounds as an argument so the slicer method knows where to start and stop cropping the image.

This feature would be very useful as a tool for developers who choose to use this package. It would make output-image validation many times easier without the need to manually calculate the bounds by comparing the original image dimensions to the slice dimensions. Developers could simply draw their selection and immediately be presented with the bounds of their slice. There would ideally be a simple "copy values" button presented as well.

Challenges and Considerations:

• This feature would essentially require designing and implementing a whole separate standalone application. While extremely useful, its workload may be outside the scope of specific package.
• The user should be able to zoom in and out down to the pixel level. Without being to see individual pixels, there would be no point to the application.
• The application should have a grid that can be toggled on and off if possible. (similar to other photo editing applications)

Example Mockup:

See the figure below as an example of what the GUI application could look/function like. Notice how in the bottom left-hand corner a rectangle is drawn and a pop-up is displayed directly to the right that lists the relevant bounds values.

Feature Outline:

Give the users the option to input a string of text as the focal-point of their rendered thumbnail rather than an embedded image. An input image could still be used as the default blurred background, but would instead have text in the foreground and no embedded image.

Why is this useful?

While thumbnails are useful for standalone videos, certain types of media such as Courses or Lectures do not have carefully-crafted thumbnails on every video. E-learning courses can easily contain hundreds of differing-length video lectures. With a high-volume of videos, it would be impractical for the creator to make a distinct thumbnail for each lecture. Therefore, we don't have to worry about losing any valuable content by replacing each video's cover with our own.

When managing hundreds of videos in a collection, it could be desirable to have them all adhere to the same visual-style. Except in this case, we could use something like each video's title and pass that in as the string to use in place of an embedded thumbnail. This would give the user an easy way to distinguish content that belongs together, but also differentiates each topic or lecture from one another.

Challenges:

• When using text in place of images, padding and font-size will have to be taken into account in order to make everything look perfect. We don't want to have text being cut-off or too squished. Therefore, additional image-validation will need to be implemented for this type of output.

Feature Outline:

Consider allowing the users to implement their own templates and styling. Could be a simple -t option that takes a template as an argument. The templates should be stored in a directory under templates/custom/ and the default could be moved under templates/default/. Each template directory would then have their own assets directory as a child.

Concerns

1. Since the current command line arguments are mostly tied to the default template, this would require a significant effort to rework the implementation of the package.

Solutions

1. An additional config file could be used to bind custom user options/arguments and flags to user-defined methods. This would require detailed documentation. If the package detects that a custom template is being used, it could switch over to only accepting options and flags from the user's config file and ignore the default ones.