[PanoTools-devel] Could not open _PTStitcher_tmp_ for writing

[Max L. <max...@ve...>]

I managed to compile the SVN version of the code today for the first time, and 
found that PTMender doesn't work, and all of the tests fail.  All attempts to 
run PTMender result in a dialog box saying "Could not open 
_PTStitcher_tmp_0000xx for writing" and then the program exits.

I've spent a few hours on it this afternoon and think I've tracked down the 
problem to the new metadata shuffling code.  Specifically, the problem is that 
in "panoTiffSetImageProperties" (line 1019 in tiff.c), the calls that set the 
samplesPerPixel and bitsPerSample are trying to use a value of zero, which is 
what the metadata struct contains.  Here's what I see in GDB at this point:

Breakpoint 4, panoTiffSetImageProperties (file=0x3f7c90) at tiff.c:1019
1019        returnValue =
1: returnValue = 1
(gdb) p *metadata
$26 = {imageWidth = 1168, imageHeight = 411, isCropped = 1,
  xPixelsPerResolution = 150, yPixelsPerResolution = 150, resolutionUnits = 2,
  samplesPerPixel = 0, bitsPerSample = 0, bytesPerLine = 0, rowsPerStrip = 1,
  compression = {type = 32773, predictor = 0}, iccProfile = {size = 0,
    data = 0x0}, cropInfo = {fullWidth = 1190, fullHeight = 418,
    croppedWidth = 1168, croppedHeight = 411, xOffset = 0, yOffset = 0},
  copyright = 0x0, datetime = 0x0, imageDescription = 0x0, artist = 0x0,
  bytesPerPixel = 0, bitsPerPixel = 0}
(gdb) n
1040        if (returnValue && metadata->bitsPerSample == 32)
1: returnValue = 0

It looks to me like these fields probably ought to have been populated at this 
point in the code, but they are still zero.  This causes PTMender to give up 
with the error message.

Because I'm not familiar with the thinking behind how all of this metadata code 
should work, I thought I'd post here and see if someone has more familiarity 
with this and knows how to fix the problem without creating more problems!

I've tried this with both JPEG and TIFF files as input, because I thought that 
the "source" metadata might be different depending on the input image format.  
The error appears with both image types.

Max




> 
> I started renaming the library to pano13. It is amazing in how many
> places it is hardcoded :) At least in the Unixes it should be building
> pano13 and installing under pano13/
> 
> In the process I also updated the version to 2.8.5pre1. I am going to
> start using -preN suffixes to make sure that we don't have binaries
> with the same library number, but different functionality. For
> instance, the idea is that we release binaries, and in the next
> functional change we update the version to the next number.
> 
> I have tested the library under OS X and Linux and it seems to be
> working (in this delta I also killed one bug I recently introduced).
> 
> 
> 
> 
> 
> --
> Daniel M. German                  "I'm crazy, but I'm not stupid"
>                                    Jackie Chan
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
> 
>  
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> PanoTools-devel mailing list
> Pan...@li...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel