Photoshop PSB file format in libpano
Jim Watters
both PSD and PSB file formats.
It was recently brought to my attention that Adobe has opened up the PSB file
format to the public in July 2010.
http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/
PSD files are limited to 30000 pixels in both directions. PSB increases this to
300000 pixels.
The extension used to save the file is not important.
The functions to write PSD will automatically save as a PSB fileformat if either
dimension is over 30000 pixels. Or a flag can be set to force the file to be PSB.
The functions to read PSD can now read both.
The last couple versions of Photoshop can now handle 16bit layers. This has been
enabled for saving PSD files. Previously when saving as a multilayer PSD file
layers were always down sampled to 8bit. This can still be forced with a flag.
Naming of the layers was changed from L01 to 001 to accommodate a larger number
of layers. Although all the layers can have the same name as far as Photoshop
is concerned.
I discovered some code that calculated the size of the data to be stored into a
size_t would fail.
I was working with an image 30100X15050 8bit/channel
// Allocate memory for one channel
count = im->width * im->height * BitsPerChannel/8 ;
channel = (unsigned char**)mymalloc( count );
width, & height are pt_int32, & BitsPerChannel is int.
Eventhough it was stored to count as size_t by the time W*H*bpc was done the
value was greater than 32bit could hold. It was turned into a a negative number,
then when assigned to count, it was ginormous. Many more terabytes than I had.
The solution was to force the calculation to use more bits.
count = (size_t)im->width * im->height * (BitsPerChannel/8) ;
I fixed what I found in libpano in file.c but there may be more like these.
I did some testing but needs more testing with a machine with more memory than
the 3GB I have. I was able to create a 5.7GB 8bit per layer file. I run out of
memory when I try the 16bit per layer file that was 30100 wide. But I could
create smaller files.
Only with the 64bit version am I able to allocate enough memory to work we these
size images.
I only have 3GB and my OS was using most of it. so I don't understand why the
64bit version was able to get the memory and the 23bit version could not.
I uploaded to SourceForge into an experimental folder a windows build 32&64bit
of the PTtiff2psd tool for testing. Use this tool to combine many tiff files
into a single multilayer PSD or PSB file.
https://sourceforge.net/projects/panotools/files/experimental/
http://wiki.panotools.org/PTtiff2psd
--
Jim Watters
http://photocreations.ca
Jeffrey Martin
I'll contact you offlist so I can help you test it, I have 24gb ready for you....
Bruno Postle
>
>I uploaded to SourceForge into an experimental folder a windows build
>32&64bit of the PTtiff2psd tool for testing. Use this tool to
>combine many tiff files into a single multilayer PSD or PSB file.
>https://sourceforge.net/projects/panotools/files/experimental/
>http://wiki.panotools.org/PTtiff2psd
Note that the Hugin .pto.mk files have a rule for assembling
multilayer PSD files using PTtiff2psd, so if you have this in your
PATH you should be able to create a multilayer PSB like this:
make -f project.pto PREFIX_multilayer.psd
..or for stacked projects:
make -f project.pto PREFIX_fused_multilayer.psd
(where PREFIX is the prefix you picked in Hugin)
--
Bruno
Joergen Geerds
btw, the 300000px limit is for the phortoshop application, not
completely for the file format. I am not sure when photoshop will
allow for larger files files, but PTGui can produce larger than 300k
PSB files, and it might be possible thatkrpano tools also accept
larger files, but I don't know yet.
it would be great if you could implement an option for the various
compression options (i.e. make packbits the default, and not ZIP)
joergen
newyorkpanorama.com
Jim Watters
The windows binary has been downloaded over 1k times with no reported problems.
It should be merged to the main trunk for next release.
I have yet to do a merge with Mercuial and with someone willing to help step me
through it I can do it.
Jim
--
Jim Watters
http://photocreations.ca
Bruno Postle
>IT has been a little over a year since this was added to a branch of libpano.
>The windows binary has been downloaded over 1k times with no reported problems.
>It should be merged to the main trunk for next release.
I can't get the PhotoshopPSB branch to build on Linux (fedora f15,
gcc 4.6.1):
ptpicker.c: In function 'Java_ptutils_CLoadImage':
ptpicker.c:362:21: error: 'pt_int32' undeclared (first use in this function)
I seem to remember Terry fixed these in the default branch, but then
if I merge the PSB branch into the default branch, then I get this
error:
pteditor.c: In function 'Java_pteditor_CGetImageRow':
pteditor.c:103:4: error: unknown type name 'UCHAR'
--
Bruno
Terry Duell
On Sat, 03 Mar 2012 09:52:29 +1100, Bruno Postle <br...@postle.net> wrote:
[snip]
> I seem to remember Terry fixed these in the default branch, but then if
> I merge the PSB branch into the default branch, then I get this error:
>
> pteditor.c: In function 'Java_pteditor_CGetImageRow':
> pteditor.c:103:4: error: unknown type name 'UCHAR'
>
It's a bit of a guess, but uchar should be defined in stdtype.h, so I
would suspect a missing #include <stdtype.h> somewhere. Try bunging it
into pteditor.c and see how that goes.
Cheers,
--
Regards,
Terry Duell
Bruno Postle
I replaced 'UCHAR' with 'unsigned char' and it builds. I've
committed this to the default branch along with the merge.
--
Bruno
Terry Duell
wrote:
[snip]
> It's a bit of a guess, but uchar should be defined in stdtype.h, so I
> would suspect a missing #include <stdtype.h> somewhere. Try bunging it
> into pteditor.c and see how that goes.
I may have been a bit premature!
I now see that uchar is defined in filters.h, which is included in
pteditor.c.
Something must be haywire somewhere as pteditor.c built OK here (Fedora
16) when I monkeyed about with the pt_int32 business.
Jim Watters
> I replaced 'UCHAR' with 'unsigned char' and it builds. I've committed this to
> the default branch along with the merge.
Terry Duell
wrote:
> On Sat, 03 Mar 2012 10:05:22 +1100, Terry Duell <tdu...@iinet.net.au>
> wrote:
> I may have been a bit premature!
> I now see that uchar is defined in filters.h, which is included in
> pteditor.c.
> Something must be haywire somewhere as pteditor.c built OK here (Fedora
> 16) when I monkeyed about with the pt_int32 business.
I now see that filter.h in the default branch prior to the PSD merge
included the following code...
//---------------------- Types
---------------------------------------------
49
50 #define UCHAR unsigned char
51 #define USHORT unsigned short
52 #define ULONG unsigned long
53
54 enum{
55 _UCHAR,
56 _USHORT,
57 _ULONG
58 };
but this code is missing in filter.h in the PSD branch and default since
the merge.
This explains why pteditor.c wouldn't build in the PSD branch.
A bit of a mystery though as to how/why it came about. Didn't anyone ever
try to build the PSD branch?
Bruno Postle
>On 2012-03-02 7:22 PM, Bruno Postle wrote:
>>I replaced 'UCHAR' with 'unsigned char' and it builds. I've
>>committed this to the default branch along with the merge.
>Thank you Bruno. I will grab and test on the weekend.
It seems the libpano13 build is now broken on Windows:
https://bugs.launchpad.net/bugs/945523
--
Bruno
Bruno Postle
>
>I now see that filter.h in the default branch prior to the PSD merge
>included the following code...
> 50 #define UCHAR unsigned char
> 51 #define USHORT unsigned short
> 52 #define ULONG unsigned long
>but this code is missing in filter.h in the PSD branch and default
>since the merge.
It seems Daniel did this a year ago: 8fbc76a7f4b9 "removed
unnecessary and duplicated data types"
--
Bruno