Skip to content

Instantly share code, notes, and snippets.

View lilith's full-sized avatar
🎯
Focusing

Lilith River lilith

🎯
Focusing
344 followers · 41 following
  • Imazen
  • Broomfield, CO
  • 23:29 (UTC -06:00)
View GitHub Profile
@lilith
lilith / uservoice.txt
Created July 15, 2015 21:21
Do you have any discounts for open-source developers using UserVoice
to support their projects? I see that you used to offer 25% and 50%
off discounts for startups - what about the people building the free software you use?
@lilith
lilith / gist:9ebdb1e0bac19cdd59da
Created June 3, 2015 20:31
java -cp ./Output/maven/classes com.drew.tools.ProcessAllImagesInFolderUtility -text "/Users/nathanael/Documents/delete/metadata-extractor-images/"
com.drew.imaging.ImageProcessingException: /Users/nathanael/Documents/delete/metadata-extractor-images/ai/BlazRobar Thinking Head Icon Set.ai [Error Extracting Metadata]
File format is not supported
com.drew.imaging.ImageProcessingException: /Users/nathanael/Documents/delete/metadata-extractor-images/crw/Canon EOS 10D.crw [Error Extracting Metadata]
File format is not supported
com.drew.imaging.ImageProcessingException: /Users/nathanael/Documents/delete/metadata-extractor-images/eps/BlazRobar Thinking Head Icon Set.eps [Error Extracting Metadata]
File format is not supported
java.lang.NoClassDefFoundError: /Users/nathanael/Documents/delete/metadata-extractor-images/jpg/Apple iPhone 4.jpg [Error Extracting Metadata]
java.lang.NoClassDefFoundError: com/adobe/xmp/XMPException
at com.drew.imaging.jpeg.JpegMetadataReader.<clinit>(JpegMetadataReader.java:53)
@lilith
lilith / perf.md
Last active August 29, 2015 14:21

Benchmarks

The following benchmarks were created by opening the FastScaling solution on commit de24b168 and running the Benchmark program in 64-bit Release mode, using an Azure D14 instance with Visual Studio 2015 RC installed. Source images are 4,000 x 4,000 jpeg images, and destination images are 800x800 jpegs.

This benchmark measures only rendering performance (it excludes jpeg encoding/decoding, which is not affected by FastScaling)

FastScaling vs DrawImage (Azure D14 instance)

This benchmark measures end-to-end image decoding, rendering, and re-encoding. It excludes I/O. FastScaling vs DrawImage (including decode and encode) (Azure D14 instance)

@lilith
lilith / blur_speed.txt
Last active August 29, 2015 14:21
Using 16 seq. runs, 2 || on 8 threads(64-bit). Segment 'bit' w/ mem barrier. Input: blank_1600x1600.png (1600x1600) (png)
Config Sequential Parallel Percent concurrent Instructions
FastScaling blur - bit 149.55ms 298.05 .. 345.55ms 82.13% t=8 ;width=800;f.blur.percent=500
bit>process>prepdest 0.77ms ||8.07ms -72.64%||
bit>process>render>managed_perform_render exclusive: 7.94ms ||8.66 .. 21.48ms|| inclusive: 148.48ms ||286.62ms 82.70%||
bit>process>render> perform_render exclusive: 0.14ms ||0.48 .. 5.68ms|| inclusive: 140.50ms ||271.69ms 81.85%||
bit>process>render> convert_srgb_to_linear 9.10ms ||17.32 .. 45.39ms -315.26%|| calls: 600
bit>process>render> ScaleBgraFloatRows 15.29ms ||26.67ms -156.24%|| calls: 600
bit>process>render> convolve kernel a exclusive: 0.04 .. 0.08ms ||0.09 .. 4.28ms|| inclusive: 96.73ms ||169.90ms 67.00%|| calls: 600
@lilith
lilith / pipeline.md
Last active August 29, 2015 14:20
ImageResizer HTTP pipeline

ImageResizer has traditionally taken a very minimalist approach to touching the HTTP pipeline.

  1. Only handle PostAuthorizeRequest and PreSendRequestHeaders events.

  2. PostAuthorizeRequest only takes action if both (a) there are image processing commands, and (b) the file has an image-type file extension.

  3. We relied on StaticFileModule to deliver cached, static assets after we called RewritePath during PostAuthorizeRequest. Our cache-miss path used a naive HttpHandler without byte-range support.

If a custom VirtualPathProvider was registered, we relied on StaticFileHandler to serve unmodifed versions of those files. Modified versions would be served either by StatciFileModule after being written to disk, or by a naive handler upon cache-miss.

@lilith
lilith / dash-rust-beta.txt
Created April 16, 2015 16:51
+ export DOCS_PATH=rust-1.0.0-beta-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html
+ DOCS_PATH=rust-1.0.0-beta-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html
+ export DOCSET_ID=rust
+ DOCSET_ID=rust
+ export 'DOCSET_NAME=Rust 1.0.0 Beta'
+ DOCSET_NAME='Rust 1.0.0 Beta'
+ export DOCSET_GROUP=rust
+ DOCSET_GROUP=rust
+ export DOCSET_GUIDES=1
+ DOCSET_GUIDES=1
@lilith
lilith / test_with_valgrind_osx
Created March 20, 2015 20:07
==39004== Memcheck, a memory error detector
==39004== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==39004== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==39004== Command: ./test_program
==39004==
--39004-- run: /usr/bin/dsymutil "./test_program"
===============================================================================
All tests passed (348 assertions in 20 test cases)
==39004==
@lilith
lilith / blocking-issues-in-dotnet.md
Last active August 29, 2015 14:17

In order to write software that targets both .NET 4.6 and .NET Core, we need .NET 4.6 to fix several oversights.

Visual studio, ASP.NET, deploy tooling, test tooling, and even the .NET runtime make some bad assumptions:

  • Every .dll is a .NET dll.
  • Managed .dlls do not depend on native .dlls
  • No project ever needs to target or deploy to more than one architecture/platform.
  • Nobody needs to adjust native or managed dll search paths at runtime.

Specifically, what low-level APIs do we need before we can fix dependency loading ourselves?

@lilith
lilith / units.json
Created January 23, 2015 22:52
{
"Name":"reunion",
"Type":"rubygem",
"Repo":"github.com/imazen/reunion",
"Globs":null,
"Files":[
"./Gemfile",
"./Gemfile.lock",
"./Rakefile",
"./banks.md",
@lilith
lilith / depresolve.json
Created January 23, 2015 22:51
[
{
"Raw": [
"byebug",
">= 0"
],
"Target": {
"ToUnit": "byebug",
"ToUnitType": "rubygem",
"ToVersionString": ">= 0",