donmccurdy

This post has been moved to my blog, under Color Management in three.js.

tomcrane

Update, March 2019

Many of the discussions below have been synthesised into this slide deck: https://docs.google.com/presentation/d/1zAmXDlfvuwlQtp9uVgFLS7RVcfNqTcyEJybnNdQ2TgY

The links below are more comprehensive and are kept here for posterity. The other document worth considering is this:

Universal Viewer design principles
(in progress) Inspired by discussions at UVCON; an attempt to set out some guiding principles for the UV; comments sought!

elebetsamer

/*
To setup, place in scripts/st-generate.js and add

"st:generate": "node scripts/st-generate.js"

To your npm scripts.

To generate a component in src/components/ run

npm run st:generate component my-component

tomcrane

This gist has been superseded by this Google Doc:

http://bit.ly/av-issues

What are Audio and Video Content APIs?

This document starts with a quick recap of IIIF Presentation and Image APIs, to help probe what is different for time-based media in the context of use cases and existing community practice for A/V today. It assumes that there is only one Presentation API, otherwise we can't have mixed-media manifests (a recurring use case and aspiration). It is based on the discussions in The Hague, in the AV Github issues and use cases, and on AV working group calls.

Introduction/recap - access to content via the Presentation API today

tomcrane

getThumbnail(..)

Motivation

Generally, to encapsulate the logic for getting the best possible thumbnail for a resource, given the user's current known auth status for those resources. Anyone using manifesto or some other library that implements this can just call getThumbnail(..) and not worry about the details. Most of the time auth is not an issue, but if it is, they still don't need to worry about the details, getThumbnail(..) will figure it out and return the best thumbnail the user can currently see (which may be no thumbnail). Crucially, getThumbnail() assumes that the best thumbnail is the FASTEST one, within reason; that viewers favour speed over a precise size because they can scale an image in the browser.

Specifically, to help viewers generate a "field" of thumbnails as quickly as possible. Mirador, UV and other viewers all show large numbers of thumbnails at once. This can give a poor user experience, especially if viewers ask for arbitrary image sizes which

tinybike

#!/bin/bash
# go-ipfs setup helper
# @author Jack Peterson ([email protected])

set -e
trap "exit" INT

IPFS_BIN="/usr/local/bin/ipfs"
IPFS_LOG="/var/log/ipfs.log"
IPFS_UPSTART="/etc/init/ipfs.conf"

xjamundx

This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.

In that post I talked about 3 main reasons for moving from require.js to webpack:

1. Common JS support
2. NPM support
3. a healthy loader/plugin ecosystem.

Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.

tomcrane

We want to move the Wellcome Library away from the Wellcome Player and onto the IIIF 2.0 Universal Viewer (UV).

This allows us to move all the Wellcome Library's image API endpoints to the protoype DLCS (Digital Library Cloud Services) that we have started building.

We have a problem. We have video, audio and born-digital content, besides image sequence content. We don't want to maintain the Player and the UV together. This non-image content is a tiny fraction of the total, but an important one.

Other institutions share this problem, and everyone agrees that IIIF will need to extend to handle non-image-sequence resources - "IxIF". We want to inherit all that we can from IIIF - the JSON-LD, the Open Annotation model, the manifest wrapper and general approach to metadata ("presentation not semantics"). Shared Canvas may be appropriate for some media but not others.

• Images are canvas-based media - they occupy a region of a plane. Annotations are on regions of the plane.
• Audio is a time-based medium - i

mdasberg

var grunt = require('grunt');
var hooker = require('hooker');

module.exports = preAndPostHook = function () {
   var currentTask = undefined;
   
   /** 
    * Do something when the task has sta.
    * @param taskName The task name.
    */

diverted247

var gulp = require( 'gulp' ),
    component = require( 'gulp-component' ),
    tsc = require( 'gulp-typescript-compiler' );

gulp.task( 'default' , [ 'ts' ] ,  function (){
    gulp.src( 'component.json' )
        .pipe( component( {
            standalone: true
        } ) )
        .pipe( gulp.dest( 'build' ) )