NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 133 - imglib: adding does not acquaint to actual type bounds
imglib: adding does not acquaint to actual type bounds
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: Plugins
unspecified
Macintosh Mac OS
: P4 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2010-02-04 10:44 CST by Jean-Yves Tinevez
Modified: 2010-02-05 10:59 CST
1 user (show)

See Also:

Description Jean-Yves Tinevez 2010-02-04 10:44:24 CST
Hi folks,

Apparently, imglib treats the bounded types (uint8, uint16) in a periodic way.

For instance, if you add 20 to a uint8 image where these is 255, the resulting intensities will be 19, not 255.

An easy way to check this is to use the templates called "Imglib Plugin" in the script editor (how do you think I found it :). Execute it on a ramp image (uint8 or uint16) to see it.


Information about your version of Java - this information is useful for the Fiji developers:
  os.arch => x86_64
  os.name => Mac OS X
  os.version => 10.5.8
  java.version => 1.6.0_17
  java.vendor => Apple Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_17-b04-248-9M3125
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 14.3-b01-101
  java.vm.vendor => Apple Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => apple.awt.CGraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => null
  file.separator => /
Comment 1 Stephan Saalfeld 2010-02-05 10:58:51 CST
Checking bounds requires two comparisons per operation and should thus not be the default.  I could imagine an extended type that does the bounds checking but have strict objections against checking bounds by default.
Comment 2 Jean-Yves Tinevez 2010-02-05 10:59:54 CST
Agreed on(In reply to comment #1)