<commit_before>'use strict';

var MagicCrop = function () {

    // Attempts to automatically calculate the cropping bound { minX, minY, maxX, maxY }
    // for the given the ImageData (https://developer.mozilla.org/en/docs/Web/API/ImageData) that contains a photo within.
    //
    // Algorithm is:
    // 1. Calculate the most popular 3 colors across the entire image. Consider these our *background* colors.
    // 2. Sample some "randomly" distributed points around the image, and from each point work in all four directions towards each edge.
    // 3. If, in any direction, we hit a *background color*, OR we make it to the *edge*, then store this as a potential cropping bound for that direction.
    // 4. For each of the 4 potential bounds calculated above, choose the most popular (mode) for each edge, to represent our final crop region.
    // 5. Apply this crop region to our original image.
    //
    // In the iOS Crop Magic app this function is called from an Angular Webworker as described here:
    // https://github.com/mattslocum/ng-webworker
    // This means it's advantageous to:
    // 1. be *Fully self contained*, so all dependent functions are defined inside it, and
    // 2. take advantage of *WebWorker transferable objects*: http://w3c.github.io/html/infrastructure.html#transferable-objects.
    // 3. This allows us to pass off the processing of each image to a backgound WebWorker...
    // 4. ...so we can try to show a *semi-decent GPU accelerated* CSS spinner as the image processing animation
    // (with admitted stutter as the image is transferred to and from the background thread!).
    //
    // Yes! This is our API these days!
    this.calcCroppingBounds = function (imageBytes, width, height) {

        // todo: Make these maguc numbers configurable? Through trial and error they work well for the general case...

        // The number of potential background color candidates to consider.
        var bgColorCount = 3;
        // When calculating the background color(s), for speed sample only 1 out of every n pixels - it's all the same really.
        var bgColorSampleRatio = 100;
        // When scanning the image for bounds, do not sample this outer fraction of the image, cos that's usually where the solid<commit_msg>Update magicCrop.js<commit_after>'use strict';

var MagicCrop = function () {

    // Attempts to automatically calculate the cropping bound { minX, minY, maxX, maxY }
    // for the given the ImageData (https://developer.mozilla.org/en/docs/Web/API/ImageData) that contains a photo within.
    //
    // Algorithm is:
    // 1. Calculate the 3 most popular colors across the entire image. Consider these our *background colors*.
    // 2. Sample some "randomly" distributed points around the image, and from each point work in all four directions towards each edge.
    // 3. If, in any direction, we hit a *background color*, OR we make it to the *edge*, then store this as a potential cropping bound for that direction.
    // 4. For each of the 4 potential bounds calculated above, choose the most popular (mode) for each edge, to represent our final crop region.
    // 5. Apply this crop region to our original image.
    //
    // In the iOS Crop Magic app this function is called from an Angular Webworker as described here:
    // https://github.com/mattslocum/ng-webworker
    // This means it's advantageous to:
    // 1. be *Fully self contained*, so all dependent functions are defined inside it, and
    // 2. take advantage of *WebWorker transferable objects*: http://w3c.github.io/html/infrastructure.html#transferable-objects.
    // 3. This allows us to pass off the processing of each image to a backgound WebWorker...
    // 4. ...so we can try to show a *semi-decent GPU accelerated* CSS spinner as the image processing animation
    // (with admitted stutter as the image is transferred to and from the background thread!).
    //
    // Yes! This is our API these days!
    this.calcCroppingBounds = function (imageBytes, width, height) {

        // todo: Make these maguc numbers configurable? Through trial and error they work well for the general case...

        // The number of potential background color candidates to consider.
        var bgColorCount = 3;
        // When calculating the background color(s), for speed sample only 1 out of every n pixels - it's all the same really.
        var bgColorSampleRatio = 100;
        // When scanning the image for bounds, do not sample this outer fraction of the image, cos that's usually where the solid
{'fraction_non_alphanumeric': 0.07828947368421052, 'fraction_numerical': 0.007456140350877193, 'mean_word_length': 2.9420916162489195, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6565079', 'n_tokens_mistral': 1203, 'n_tokens_neox': 1136, 'n_words': 610}