cornerstone-core - npm Package Compare versions

Comparing version 0.13.2 to 1.0.0

package.json

 {
   "name": "cornerstone-core",
-  "version": "0.13.2",
+  "version": "1.0.0",
   "description": "HTML5 Medical Image Viewer Component",
@@ -5,0 +5,0 @@ "main": "./dist/cornerstone.js",

README.md

@@ -7,29 +7,13 @@ [![NPM version][npm-version-image]][npm-url] [![NPM downloads][npm-downloads-image]][npm-url] [![MIT License][license-image]][license-url] [![Build Status][travis-image]][travis-url]
 
-Cornerstone is an open source project with a goal to deliver a complete web based medical imaging platform.  This
-repository contains the Cornerstone Core component which is a lightweight JavaScript library for displaying
-medical images in modern web browsers that support the HTML5 canvas element.
-Cornerstone Core is not meant to be a complete application itself, but instead a component
-that can be used as part of larger more complex applications.  See the
+Cornerstone is an open source project with a goal to deliver a complete web based medical imaging platform. This repository contains the Cornerstone Core component which is a lightweight JavaScript library for displaying medical images in modern web browsers that support the HTML5 canvas element. Cornerstone Core is not meant to be a complete application itself, but instead a component that can be used as part of larger more complex applications.  See the
 [OHIF Viewer](http://viewer.ohif.org/) for an example of using the various Cornerstone
 libraries to build a simple study viewer.
 
-Cornerstone Core is agnostic to the actual container used to store image pixels as well as the transport mechanism
-used to get the image data.  In fact, Cornerstone Core itself has no ability to read/parse or load images and instead
-depends on one or more [ImageLoaders](https://github.com/chafey/cornerstone/wiki/ImageLoader) to function.
-The goal here is to avoid constraining developers to work within a single container and transport (e.g. DICOM) since
-images are stored in a variety of formats (including proprietary).  By providing flexibility with respect to the
-container and transport, the highest performance image display may be obtained as no conversion to an alternate
-container or transport is required.  It is hoped that developers feel empowered to load images from any type of image
-container using any kind of transport.  See the
-[CornerstoneWADOImageLoader](https://github.com/chafey/cornerstoneWADOImageLoader) project for an example
+Cornerstone Core is agnostic to the actual container used to store image pixels as well as the transport mechanism used to get the image data.  In fact, Cornerstone Core itself has no ability to read/parse or load images and instead depends on one or more [ImageLoaders](https://github.com/chafey/cornerstone/wiki/ImageLoader) to function.
+
+The goal here is to avoid constraining developers to work within a single container and transport (e.g. DICOM) since images are stored in a variety of formats (including proprietary).  By providing flexibility with respect to the container and transport, the highest performance image display may be obtained as no conversion to an alternate container or transport is required.  It is hoped that developers feel empowered to load images from any type of image container using any kind of transport.  See the [CornerstoneWADOImageLoader](https://github.com/chafey/cornerstoneWADOImageLoader) project for an example
 of a DICOM WADO based Image Loader.
 
-Cornerstone Core is agnostic to the exact interaction paradigm being used.  It does not include any mouse, touch or
-keyboard bindings to manipulate the various image properties such as scale, translation or ww/wc.  The goal here
-is to avoid constraining developers using this library to fit into a given ui paradigm.  It is hoped that developers
-are empowered to create new paradigms possibly using new input mechanisms to interact with medical images (e.g.
-[Kinect](http://en.wikipedia.org/wiki/Kinect) or [Accelerometer](http://en.wikipedia.org/wiki/Accelerometer).
-Cornerstone does provide a set of API's allowing manipulation of the image properties via javascript.
-See the [CornerstoneTools](https://github.com/chafey/cornerstoneTools) library for an example of common tools built on top of
-Cornerstone.
+Cornerstone Core is agnostic to the exact interaction paradigm being used.  It does not include any mouse, touch or keyboard bindings to manipulate the various image properties such as scale, translation or ww/wc.  The goal here is to avoid constraining developers using this library to fit into a given ui paradigm.  It is hoped that developers are empowered to create new paradigms possibly using new input mechanisms to interact with medical images (e.g. [Kinect](http://en.wikipedia.org/wiki/Kinect) or [Accelerometer](http://en.wikipedia.org/wiki/Accelerometer).
+Cornerstone does provide a set of API's allowing manipulation of the image properties via javascript. See the [CornerstoneTools](https://github.com/chafey/cornerstoneTools) library for an example of common tools built on top of Cornerstone.
 
@@ -91,2 +75,4 @@ Community
 
+[CornerstoneWebImageLoader](https://github.com/chafey/cornerstoneWebImageLoader) - A Cornerstone Image Loader that works with PNG and JPEG files
+
 [dicomParser](https://github.com/chafey/dicomParser) - A JavaScript library designed to parse DICOM for web browsers
@@ -164,4 +150,3 @@
 
-This library would be responsible for displaying the rendered image to the user.  The rendering of the
-3D image would be done by some other library - perhaps on the server side.  This library is purely 2D and has no knowledge of 3D image space.  It will probably make sense to have several layers on top of this library to provide 3D functionality.  For example, one layer that has a 3D viewport with properties such as transformation matrix, slice thickness, transfer function/LUT, segmentation masks, etc.  And another 3D tools layer that provides various tools on top of the 3d viewport (rotate, zoom, segment, scroll, etc).
+This library would be responsible for displaying the rendered image to the user.  The rendering of the 3D image would be done by some other library - perhaps on the server side.  This library is purely 2D and has no knowledge of 3D image space.  It will probably make sense to have several layers on top of this library to provide 3D functionality.  For example, one layer that has a 3D viewport with properties such as transformation matrix, slice thickness, transfer function/LUT, segmentation masks, etc.  And another 3D tools layer that provides various tools on top of the 3d viewport (rotate, zoom, segment, scroll, etc).
 
@@ -173,3 +158,3 @@ OHIF/Cornerstone is working with the 3DSlicer project to integrate the two.  I also expect to implement
 
-Primarily for its custom event handling.
+Primarily for its custom event handling. This is being transitioned out and will be gone for 2.0.0.
 
@@ -200,3 +185,3 @@ _I would like to contribute code - how do I do this?_
 
-Copyright 2016 Chris Hafey [[e-mail]](mailto:[e-mail])
+Copyright 2017 Chris Hafey [[e-mail]](mailto:[e-mail])
 
@@ -203,0 +188,0 @@ [license-image]: http://img.shields.io/badge/license-MIT-blue.svg?style=flat

Fixed alerts

Deprecated

Maintenance

The maintainer of the package marked it as deprecated. This could indicate that a single version should not be used, or that the package is no longer maintained and any new vulnerabilities will not be fixed.

Found 1 instance in 1 package

No v1

Quality

Package is not semver >=1. This means it is not stable and does not support ^ ranges.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

1469822

increased by0.01%

Number of medium maintenance alerts

0

decreased by-100%

Number of low quality alerts

0

decreased by-100%

Worsened metrics

Number of lines in readme file

194

decreased by-7.18%

No dependency changes