 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1
Hi,
This is my first post here. My name is Don and I am concentrating on making very large panos. I look forward to sharing my experiences and getting help with my problems. Unfortunately, my first post is about a problem.
I am using AutoPano Pro 64-bit running on a XP-64 system with 4G of RAM. My very first attempt at rendering a pano with the 64-bit system was a stitch made from 549 images. It rendered fine and quite fast (once I changed from Smartblend to Multiband), creating an 8-bit psb file which is 4G in size. But when I tried opening the image in CS3, it told me that it couldn't open the file because an unexpected EOF was encountered. Is this a known problem? Any solution? Thanks?
Don
Offline
FWIW, the actual file size is 4,194,270, only 34 bytes short of exactly 4G. Not sure if that is meaningful or just coincidence.
Offline
panoperson wrote:
FWIW, the actual file size is 4,194,270, only 34 bytes short of exactly 4G. Not sure if that is meaningful or just coincidence.
As a Mac-User i can´t says something helpful about Windows. CS3 doesn´t have a problem with bigger than 4GB files on Mac.
Maybe you need more free diskspace reserved for APP or it maybe a RAM issue.
I use to have such big sizes and realized that 4GB RAM is very small for those - after using 8GB it`s running better.
I heard about problems of the Windows files-ystem with files bigger than 4GB . . which file-system do you use?
best, Klaus
Offline
This is clearly due to something from outside autopano :
- check the file system
- space left on the drive
- did you use a network drive
Offline
klausesser wrote:
panoperson wrote:
FWIW, the actual file size is 4,194,270, only 34 bytes short of exactly 4G. Not sure if that is meaningful or just coincidence.
As a Mac-User i can´t says something helpful about Windows. CS3 doesn´t have a problem with bigger than 4GB files on Mac.
Maybe you need more free diskspace reserved for APP or it maybe a RAM issue.
I use to have such big sizes and realized that 4GB RAM is very small for those - after using 8GB it`s running better.
I heard about problems of the Windows files-ystem with files bigger than 4GB . . which file-system do you use?
best, Klaus
The file system is FAT32 and has 400 GB free, so it isn't for lack of disk space. The file is 34 bytes less than 4GB so it isn't related to files larger than 4GB. The fact that its size is so close to 4GB made me think that the problem might be with APP - maybe a boundary bug of some sort.
Don
Offline
AlexandreJ wrote:
This is clearly due to something from outside autopano :
- check the file system
- space left on the drive
- did you use a network drive
Clearly? How so? It doesn't appear to be related to the file system or the drive (local drive).
Offline
After it happened again with a completely different stitch and the output file was only 20 bytes short of 4G, I researched FAT32 and discovered that it is limited to 4GB file sizes. However, AutoPano Pro does not recognize this as a problem situation or report it to the user. It simply writes the first 4GB of the file and then says it did a successful rendering. I don't know if this can be considered a bug or not.
Don
Offline
If the low-level file system routines do not not report errors (which I suspect), APP can't do better...
Offline
panoperson wrote:
After it happened again with a completely different stitch and the output file was only 20 bytes short of 4G, I researched FAT32 and discovered that it is limited to 4GB file sizes. However, AutoPano Pro does not recognize this as a problem situation or report it to the user. It simply writes the first 4GB of the file and then says it did a successful rendering. I don't know if this can be considered a bug or not.
Don
Don
Why are you using the FAT32 file system? Which version of Windows are you using? Convert your volume to NTFS.
Offline
It wasn't a deliberate choice. That is what the USB drive I was using came with. Yes, of course I converted it once I knew what the problem was.
Offline
panoperson wrote:
It wasn't a deliberate choice. That is what the USB drive I was using came with. Yes, of course I converted it once I knew what the problem was.
Good - I just mentioned it because I know some people who wouldn't know that you can convert the filesystem type.
Offline
Did you try the rendering again on another filesystem ? Could you confirm us that it worked ?
fma38 wrote:
If the low-level file system routines do not not report errors (which I suspect), APP can't do better...
So true.
Offline
AlexandreJ wrote:
Did you try the rendering again on another filesystem ? Could you confirm us that it worked ?
Yes, I changed the file system to NTFS and it rendered fine.
Offline
AlexandreJ wrote:
Did you try the rendering again on another filesystem ? Could you confirm us that it worked ?
fma38 wrote:
If the low-level file system routines do not not report errors (which I suspect), APP can't do better...
So true.
But it is possible to programmatically detect the kind of file system in use on a given drive. It took me a while to verify this but now I am certain. So APP could check to see if the file size was compatible with the file system of the selected drive and notify the user if it is not.
Offline
Yes, that could a check we can had. Seems simple but it is not at all to code when working with cross-platform technology.
This will need a library we have to develop 3 times ( windows, mac, linux ) that can access to the low level part of the file system. Then, we'll need to find out what is the limit of the current file system : NTFS v1, v1.1, et FAT16, FAT32, FAT32 extended, ext3, xfs ...
This is quite a 2 weeks task.
Offline
OK. Then maybe you could include a mention in the documentation of what file systems to avoid and what the problem probably is if your broken output file is within a few bytes of 4GB.
Offline
Another way around this may be to check the file size the file system reports compared to what APP thinks it wrote.
Not a great solution, but the user gets an error message, and doesn't have to figure out why .PSBs don't work, And he only has to go through one render to find out he has to convert to NTFS.
Offline
Pages: 1
