AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
November 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2009.11.02 17:51 "Tiffcrop test suite", by Richard Nolde
2009.11.02 21:59 "Tiffcrop test suite and logluv issues", by Richard Nolde
2009.11.02 23:02 "Re: Tiffcrop test suite and logluv issues", by Toby Thain
2009.11.03 10:14 "Re: Tiffcrop test suite and logluv issues", by Juergen Buchmueller
2009.11.03 12:16 "Re: Tiffcrop test suite and logluv issues", by Toby Thain
2009.11.03 13:23 "What are the LibTIFF v4.0 release plans?", by Steve Eddins
2009.11.03 14:37 "Re: What are the LibTIFF v4.0 release plans?", by Bob Friesenhahn
2009.11.03 15:00 "Re: What are the LibTIFF v4.0 release plans?", by Steve Eddins
2009.11.04 02:30 "Re: What are the LibTIFF v4.0 release plans?", by Jay Berkenbilt
2009.11.03 20:46 "Re: Tiffcrop test suite and logluv issues", by Daniel Mccoy
2009.11.04 08:45 "Re: Tiffcrop test suite and logluv issues", by Juergen Buchmueller
2009.11.04 15:49 "Re: Tiffcrop test suite and logluv issues", by Toby Thain

2009.11.02 23:02 "Re: Tiffcrop test suite and logluv issues", by Toby Thain

On 2-Nov-09, at 4:59 PM, Richard Nolde wrote:

> ...
> Every pixel shows at least one change for sample 0, a few pixels show
> multiple changes.  Since tiffcp doesn't do anything but copy  
> scanlines,
> unlike tiffcrop which loads the image into memory so that it can be
> manipulated, it is hard to figure out why the data would change  
> unless,
> as I suspect, the following code from tif_luv.c doesn't take into
> consideration the fact that the original data is bigendian and I am
> compiling on a little endian host (having just gone through this with
> Toby's patch suggestion.)  In fact, running tiffcp or tiffcrop with  
> the
> -B switch to generate big endian TIFF produces quite a different  
> result
> for both off_luv24.tif and off_luv32.tif.
>
> LogLuvDecode24(TIFF* tif, tidata_t op, tsize_t occ, tsample_t s)
> {
>          LogLuvState* sp = DecoderState(tif);
>          int cc, i, npixels;
>          unsigned char* bp;
>          uint32* tp;
>
>          assert(s == 0);
>          assert(sp != NULL);
>
>          npixels = occ / sp->pixel_size;
>
>          if (sp->user_datafmt == SGILOGDATAFMT_RAW)
>                  tp = (uint32 *)op;
>          else {
>                  assert(sp->tbuflen >= npixels);
>                  tp = (uint32 *) sp->tbuf;
>          }
>                                          /* copy to array of uint32 */
>          bp = (unsigned char*) tif->tif_rawcp;
>          cc = tif->tif_rawcc;
>          for (i = 0; i < npixels && cc > 0; i++) {
>                  tp[i] = bp[0] << 16 | bp[1] << 8 | bp[2];

^^ This is a portable way of decoding a 3-byte BigEndian value. It  
will work on any host.

--Toby

>                  bp += 3;
>                  cc -= 3;
>          }
>
> Richard Nolde
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/