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
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.
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.
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:
I agree with jeffrey, great work, it was something I was waiting for.
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)
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 have yet to do a merge with Mercuial and with someone willing to help step me through it I can do it.
> 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)
On Thu 01-Mar-2012 at 12:39 -0400, Jim Watters wrote:
>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'
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.
On Sat 03-Mar-2012 at 10:05 +1100, Terry Duell wrote:
>On Sat, 03 Mar 2012 09:52:29 +1100, Bruno Postle <br...@postle.net> wrote:
>>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.
I replaced 'UCHAR' with 'unsigned char' and it builds. I've committed this to the default branch along with the merge.
On Sat, 03 Mar 2012 10:05:22 +1100, Terry Duell <tdu...@iinet.net.au> 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.
On Sat, 03 Mar 2012 10:18:07 +1100, Terry Duell <tdu...@iinet.net.au> 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?
On Fri 02-Mar-2012 at 23:28 -0400, Jim Watters wrote:
>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:
On Sun 04-Mar-2012 at 10:31 +1100, Terry Duell wrote:
>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"
