Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-s.b-one.net (mx-s.one.com [91.198.169.250])
	by mail9.b-one.net (Postfix) with ESMTP id BC37C40013B
	for <info@awaresystems.be>; Thu, 28 Jul 2011 02:58:56 +0200 (CEST)
Received: by mx-s.b-one.net (Postfix, from userid 106)
	id AEFA4B52DA3; Thu, 28 Jul 2011 02:58:18 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-s.b-one.net (Postfix) with ESMTP id 126CAB52DA2 for
 <info@awaresystems.be>; Thu, 28 Jul 2011 02:58:18 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 8796D872E3; Wed, 27 Jul 2011
 19:57:13 -0500 (EST)
Received: from cmx.pixar.com (cmx.pixar.com [12.25.180.66]) by
 lists.maptools.org (Postfix) with ESMTP id 2CE49872C6 for
 <tiff@lists.maptools.org>; Wed, 27 Jul 2011 19:45:32 -0500 (EST)
X-PixarMID: 22164303
X-PixarRecvListener: OutboundMail
X-PixarRemoteIP: 138.72.134.130
X-IronPort-AV: E=Sophos;i="4.67,279,1309762800"; d="scan'208";a="22164303"
Received: from melete.dynamic.pixar.com ([138.72.134.130]) by
 cirrus.pixar.com with ESMTP; 27 Jul 2011 17:45:32 -0700
Received: from melete.dynamic.pixar.com (localhost [127.0.0.1]) by
 melete.dynamic.pixar.com (8.14.3/8.14.3) with ESMTP id p6S0jVek006930; Wed,
 27 Jul 2011 17:45:32 -0700
Received: (from mccoy@localhost) by melete.dynamic.pixar.com
 (8.14.3/8.14.3/Submit) id p6S0jVLj006928; Wed, 27 Jul 2011 17:45:31 -0700
Date: Wed, 27 Jul 2011 17:45:31 -0700
From: Daniel McCoy <mccoy@pixar.com>
To: "Terry L. Sprout" <Terry.Sprout@Agile-Automation.com>
Message-ID: <20110728004531.GA6317@pixar.com>
References:
 <6EF72F8D2EC2184184FB2204784CBCD318769B@AgileServer.AgileDomain.local>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To:
 <6EF72F8D2EC2184184FB2204784CBCD318769B@AgileServer.AgileDomain.local>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] Using photon lists rather than rasters
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Reading these photon files would require rendering to convert
them into the kind of raster image that TIFF readers expect.

There should be other file formats which might be more suited for this.
An example would be RenderMan's "point cloud" file:

    http://cgkit.sourceforge.net/doc2/pointcloud.html



From "Terry L. Sprout" <Terry.Sprout@Agile-Automation.com>, Wed, Jul 27, 2011 at 09:39:00AM -0700:
> Hello,
> 
>  
> 
> I write Scientific Imaging software that writes TIFF files. I recently
> add the ability to locate photons in an image with sub-pixel accuracy.
> The original image is then discarded and a new image can be created from
> the list of photons. I want to write a TIFF file that provides this list
> instead of the standard raster image. I already registered an IFD tag
> with Adobe for this purpose and I already devised a scheme.
> 
>  
> 
> I am interested in knowing if this has already been defined since it
> would be advantageous to use known schemes so other TIFF readers can
> understand these files. The whole purpose of using TIFF files is to
> create files that can be read by others, and I would like to continue.
> 
>  
> 
> I am also interested in knowing if more bits in the NewSubfileType have
> already been defined. I think these files should be identified with a
> bit set so the reader knows the image is defined by a series of
> coordinates rather than a series of strips. How do I register a new bit?
> 
>  
> 
> This also begs the question of how other readers will handle a file with
> no strips. Of course, I'm not quite sure how that would be done. It
> seems the best way to provide an empty image is to set the
> StripByteCount tag to 0. I assume the StipOffset tag cannot be zero
> since that simply points to the beginning of the file, the RowsPerStrip
> tag cannot be zero since that might cause a divide-by-zero error for
> those readers that calculate the number of strips per image.
> 
>  
> 
> Perhaps this could be considered a new compression type instead (no need
> for a sub file type). How do I register a compression type, or is there
> already one that exists for coordinate-based pixels? (The coordinates
> must be floating-points since they represent sub-pixel accuracy.)
> 
>  
> 
>  
> 
> Terry L. Sprout
> 
> (510) 324-5501
> 
> w7-32
> 
>  
> 

> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
