Tiffcrop test suite
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
Tiffcrop test suite
by Richard Nolde-2
::
Rate this Message:
The CVS Head version includes the test suite commands for tiffcrop.
Two of the files in the set currently fail for the extract option because the image is smaller than the dimensions of the requested region, eg 100x100 pixels. The image dimensions for the files are listed below. Changing the -X 100 -Y 100 arguments in tiffcrop-extract* to -X 60 -Y 60 would allow all but the logluv-3c-16b.tif image to pass. The libtiffpic testsuite already contains two logluv images libtiffpic/off_luv24.tif and libtiffpic/off_luv32.tif. My testing with the first produces a mostly white output image with two yellow squares whereas the second one works fine. Tiffcp does the same so I suspect the issue is in handling the logluv24 compression in the copytags logic. I'll see if I can look into this today but I don't know much about logluv. #!/bin/sh # Generated file, master is Makefile.am . ${srcdir:-.}/common.sh infile="$srcdir/images/minisblack-2c-8b-alpha.tiff" outfile="o-tiffcrop-extract-minisblack-2c-8b-alpha.tiff" f_test_convert "$TIFFCROP -U px -E top -X 100 -Y 100" $infile $outfile f_tiffinfo_validate $outfile tiffcrop-extract-minisblack-2c-8b-alpha.sh images/logluv-3c-16b.tiff Image Width: 1 Image Length: 1 images/minisblack-1c-16b.tiff Image Width: 157 Image Length: 151 images/minisblack-1c-8b.tiff Image Width: 157 Image Length: 151 images/minisblack-2c-8b-alpha.tiff Image Width: 64 Image Length: 64 images/miniswhite-1c-1b.tiff Image Width: 157 Image Length: 151 images/palette-1c-1b.tiff Image Width: 157 Image Length: 151 images/palette-1c-4b.tiff Image Width: 157 Image Length: 151 images/palette-1c-8b.tiff Image Width: 157 Image Length: 151 images/rgb-3c-16b.tiff Image Width: 157 Image Length: 151 images/rgb-3c-8b.tiff Image Width: 157 Image Length: 151 _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
|
|
|
Re: Tiffcrop test suite and logluv issues
by Toby Thain-2
::
Rate this Message:
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@... > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop test suite and logluv issues
by Juergen Buchmueller
::
Rate this Message:
On Mon, 02 Nov 2009 14:59:43 -0700
Richard Nolde <richard.nolde@...> wrote: [snap] > 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.) [snip] > for (i = 0; i < npixels && cc > 0; i++) { > tp[i] = bp[0] << 16 | bp[1] << 8 | bp[2]; > bp += 3; > cc -= 3; > } As Toby said, this is endian safe. We've used it over and over again when coding CPU emulations for MAME :) But didn't your compiler warn you about the ambiguity of the Shift-Left / OR expression? AFAIK one should put parens around the shifted terms to tell the compiler that the shift has precedence over the OR. I.e. you don't want bp[0] << (16 | bp[1]), which in theory is a valid way to reduce the expression. Alternatively one could write: tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2]; Compilers today transform the power-of-two multiplications into rather effective code (read: shift lefts) and it doesn't require parens. HTH Juergen _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop test suite and logluv issues
by Toby Thain-2
::
Rate this Message:
On 3-Nov-09, at 5:14 AM, Juergen Buchmueller wrote: > On Mon, 02 Nov 2009 14:59:43 -0700 > Richard Nolde <richard.nolde@...> wrote: > > [snap] >> 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.) > [snip] >> for (i = 0; i < npixels && cc > 0; i++) { >> tp[i] = bp[0] << 16 | bp[1] << 8 | bp[2]; >> bp += 3; >> cc -= 3; >> } > > As Toby said, this is endian safe. We've used it over and over again > when coding CPU emulations for MAME :) > > But didn't your compiler warn you about the ambiguity of the > Shift-Left / OR expression? It's not ambiguous to the compiler - only to humans who haven't internalised the precedence chart :) > AFAIK one should put parens around the > shifted terms to tell the compiler that the shift has precedence over > the OR. I.e. you don't want bp[0] << (16 | bp[1]), which in theory > is a > valid way to reduce the expression. It is not a valid translation! A C compiler must obey precedence (<< is higher than |). However, again, for clarity I would always use parentheses though they are redundant for correct evaluation. > > Alternatively one could write: > tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2]; > > Compilers today transform the power-of-two multiplications into rather > effective code (read: shift lefts) and it doesn't require parens. This adds to the cognitive load for humans. A shift shows the intent more clearly. --Toby > > HTH > Juergen > _______________________________________________ > Tiff mailing list: Tiff@... > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
What are the LibTIFF v4.0 release plans?
by Steve Eddins
::
Rate this Message:
Hi,
Are there any plans to do a final release of LibTIFF v4.0? --- Steve Eddins Image Processing and Geospatial Computing Group The MathWorks, Inc. _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: What are the LibTIFF v4.0 release plans?
by Bob Friesenhahn
::
Rate this Message:
On Tue, 3 Nov 2009, Steve Eddins wrote:
> Are there any plans to do a final release of LibTIFF v4.0? No doubt there will be a final release. Unfortunately, there has not been much feedback from users yet other than a few bug reports of malfunctions and compiler warnings. We are hoping to hear more feedback from libtiff API users. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: What are the LibTIFF v4.0 release plans?
by Steve Eddins
::
Rate this Message:
OK, thanks. I'll ask my team to do an evaluation.
-----Original Message----- From: Bob Friesenhahn [mailto:bfriesen@...] Sent: Tuesday, November 03, 2009 9:37 AM To: Steve Eddins Cc: 'tiff@...' Subject: Re: [Tiff] What are the LibTIFF v4.0 release plans? On Tue, 3 Nov 2009, Steve Eddins wrote: > Are there any plans to do a final release of LibTIFF v4.0? No doubt there will be a final release. Unfortunately, there has not been much feedback from users yet other than a few bug reports of malfunctions and compiler warnings. We are hoping to hear more feedback from libtiff API users. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop test suite and logluv issues
by Daniel McCoy
::
Rate this Message:
From Toby Thain <toby@...>, Tue, Nov 03, 2009 at 07:16:07AM -0500:
> > > > Alternatively one could write: > > tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2]; > > > > Compilers today transform the power-of-two multiplications into rather > > effective code (read: shift lefts) and it doesn't require parens. > > This adds to the cognitive load for humans. A shift shows the intent > more clearly. True. One way of reducing the cognitive load in the multiply version is to use hex constants: tp[i] = 0x10000 * bp[0] + 0x100 * bp[1] + bp[2]; which show the intent more clearly than the decimal constants. _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: What are the LibTIFF v4.0 release plans?
by Jay Berkenbilt-2
::
Rate this Message:
Bob Friesenhahn <bfriesen@...> wrote:
> No doubt there will be a final release. Unfortunately, there has not > been much feedback from users yet other than a few bug reports of > malfunctions and compiler warnings. We are hoping to hear more > feedback from libtiff API users. I'll put out a request on the debian developer list for people to test. 4.0 beta 4 is in debian's experimental release. -- Jay Berkenbilt <ejb@...> _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop test suite and logluv issues
by Juergen Buchmueller
::
Rate this Message:
On Tue, 3 Nov 2009 12:46:26 -0800
Daniel McCoy <mccoy@...> wrote: > From Toby Thain <toby@...>, Tue, Nov 03, 2009 at 07:16:07AM -0500: > > > > > > Alternatively one could write: > > > tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2]; > > > > > > Compilers today transform the power-of-two multiplications into rather > > > effective code (read: shift lefts) and it doesn't require parens. > > > > This adds to the cognitive load for humans. A shift shows the intent > > more clearly. > > True. > One way of reducing the cognitive load in the multiply version > is to use hex constants: > > tp[i] = 0x10000 * bp[0] + 0x100 * bp[1] + bp[2]; > > which show the intent more clearly than the decimal constants. I don't agree, but that may be due to me recognizing powers of two in decimal just as well as in hex .. at least up to 2^20. Here's a suggestion for the ambitious commenter: #define SHL24(x) 0x1000000*(x) #define SHL16(x) 0x10000*(x) #define SHL8(x) 0x100*(x) tp[i] = SHL16(bp[0]) + SHL8(bp[1]) + bp[2]; ;-) Juergen _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
|
|
Re: Tiffcrop test suite and logluv issues
by Toby Thain-2
::
Rate this Message:
On 4-Nov-09, at 3:45 AM, Juergen Buchmueller wrote: > On Tue, 3 Nov 2009 12:46:26 -0800 > Daniel McCoy <mccoy@...> wrote: > >> From Toby Thain <toby@...>, Tue, Nov 03, 2009 at >> 07:16:07AM -0500: >>>> >>>> Alternatively one could write: >>>> tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2]; >>>> >>>> Compilers today transform the power-of-two multiplications into >>>> rather >>>> effective code (read: shift lefts) and it doesn't require parens. >>> >>> This adds to the cognitive load for humans. A shift shows the intent >>> more clearly. >> >> True. >> One way of reducing the cognitive load in the multiply version >> is to use hex constants: >> >> tp[i] = 0x10000 * bp[0] + 0x100 * bp[1] + bp[2]; >> >> which show the intent more clearly than the decimal constants. > > I don't agree, but that may be due to me recognizing powers of two in > decimal just as well as in hex .. at least up to 2^20. Sure, most of us can, but why depend on an *arbitrary* reader also having that ability when there are clearer ways of expressing it? (Multiplication by hex constant seems like one way, though I don't do this in my own code.) *Unless* the reader has memorised powers of binary like you, the function of decimal literals here are less clear, and should be avoided for maintainability reasons, imho (since we have the choice). Plus, shift is more expressive of the intent than multiply, imho. > > Here's a suggestion for the ambitious commenter: > > #define SHL24(x) 0x1000000*(x) > #define SHL16(x) 0x10000*(x) > #define SHL8(x) 0x100*(x) > > tp[i] = SHL16(bp[0]) + SHL8(bp[1]) + bp[2]; I don't find this clearer than bitshifts, in fact, hiding the operation in macros looks like obfuscation. (Plus for better documentation value, the macro/function could be on the "read 3 bytes BigEndian" level.) If the putative reader cannot parse << 8 as "shift left 8 bits", then they are going to have bigger problems working in C. A "SHL8" macro won't save them. But this digression is surely dead and buried by now... --Toby > > ;-) > > Juergen > _______________________________________________ > Tiff mailing list: Tiff@... > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ _______________________________________________ Tiff mailing list: Tiff@... http://lists.maptools.org/mailman/listinfo/tiff http://www.remotesensing.org/libtiff/ |
| Free embeddable forum powered by Nabble | Forum Help |
