From: dmg <dm...@uv...> - 2011-02-14 02:29:30
|
Hi Jim, I think this is great. I have always wanted 16-bit support in PSD files. One suggestion: There is a lot of cloning in the new code: if(bBig) 1.243 { 1.244 WRITESHORT( 0 ); // red 1.245 - WRITEINT64( channelLength64 ) // Length of following channel data. 1.246 + WRITEINT64( channelLength ) // Length of following channel data. 1.247 WRITESHORT( 1 ); // green 1.248 - WRITEINT64( channelLength64 ) // Length of following channel data. 1.249 + WRITEINT64( channelLength ) // Length of following channel data. 1.250 WRITESHORT( 2 ); // blue 1.251 - WRITEINT64( channelLength64 ) // Length of following channel data. 1.252 + WRITEINT64( channelLength ) // Length of following channel data. 1.253 if( hasClipMask ) // Mask channel 1.254 { 1.255 WRITESHORT( -1); // Shape Mask 1.256 - WRITEINT64( channelLength64 ); // Length of following channel data. 1.257 + WRITEINT64( channelLength ); // Length of following channel data. 1.258 WRITESHORT( -2); // Clip Mask 1.259 - WRITEINT64( channelLength64 ); // Length of following channel data. 1.260 + WRITEINT64( channelLength ); // Length of following channel data. 1.261 } 1.262 } 1.263 else 1.264 { 1.265 WRITESHORT( 0 ); // red 1.266 - WRITEINT32( channelLength ) // Length of following channel data. 1.267 + WRITEINT32( (pt_uint32)channelLength ) // Length of following channel data. 1.268 WRITESHORT( 1 ); // green 1.269 - WRITEINT32( channelLength ) // Length of following channel data. 1.270 + WRITEINT32( (pt_uint32)channelLength ) // Length of following channel data. 1.271 WRITESHORT( 2 ); // blue 1.272 - WRITEINT32( channelLength ) // Length of following channel data. 1.273 + WRITEINT32( (pt_uint32)channelLength ) // Length of following channel data. 1.274 if( hasClipMask ) // Mask channel 1.275 { 1.276 WRITESHORT( -1); // Shape Mask 1.277 - WRITEINT32( channelLength ); // Length of following channel data. 1.278 + WRITEINT32( (pt_uint32)channelLength ); // Length of following channel data. 1.279 WRITESHORT( -2); // Clip Mask 1.280 - WRITEINT32( channelLength ); // Length of following channel data. 1.281 + WRITEINT32( (pt_uint32)channelLength ); // Length of following channel data. 1.282 } 1.283 } The execution paths are almost identical, except for the call to WRITEINT32 or WRITEINT64. Why not write a new macro, called WRITEINT that takes the bBig as a flag, so the code will look like this instead: It would be easier to maintain, than to have two almost identical execution paths. I presume this is not always an option, but it would be easier to really maintain as close as possible the execution path of both. We should also add a test for this, to avoid regressions to the current execution path. --dmg WRITESHORT( 0 ); // red WRITEINT( channelLength, bBig ) // Length of following channel data. WRITEINT( (pt_uint32)channelLength, bBig ) // Length of following channel data. WRITESHORT( 1 ); // green WRITEINT (channelLength, bBig ) // Length of following channel data. WRITEINT (pt_uint32)channelLength, bBig ) // Length of following channel data. WRITESHORT( 2 ); // blue WRITEINT( channelLength, bBig ) // Length of following channel data. WRITEINT (pt_uint32)channelLength, bBig ) // Length of following channel data. if( hasClipMask ) // Mask channel { WRITESHORT( -1); // Shape Mask WRITEINT( channelLength, bBig ); // Length of following channel data. WRITEINT( (pt_uint32)channelLength, bBig ); // Length of following channel data. WRITESHORT( -2); // Clip Mask WRITEINT( channelLength , bBig); // Length of following channel data. WRITEINT( (pt_uint32)channelLength, bBig ); // Length of following channel data. } } On Sun, Feb 13, 2011 at 1:51 PM, Jim Watters <jwa...@ph...> wrote: > I have committed changes to a PhotoshopPSB branch of libpano that can handle > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Hugin and other free panoramic software" group. > A list of frequently asked questions is available at: > http://wiki.panotools.org/Hugin_FAQ > To post to this group, send email to hug...@go... > To unsubscribe from this group, send email to > hug...@go... > For more options, visit this group at > http://groups.google.com/group/hugin-ptx > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: Jim W. <jwa...@ph...> - 2011-02-17 22:59:06
|
On 2011-02-14 8:46 AM, dmg wrote: > Hi Jim, > > I spent some time tonight reading the spec. It seems that only some > fields can be "64" or "32" based on the bBig flag. I think it would > be a good idea to use a macro that is only used when a variable field > is expected. It seems that the order of other fields (and their > occupancy) is the same for both types of files. > > --dmg I have updated the code to use functions instead of the macros. And I created one function for writing 64or32 and one function for reading 64or32. The write functions return amount written so they can be concatenated together and the total used to later write the final size. Next step is to create a new function to continuously write the layers. -- Jim Watters http://photocreations.ca |
From: dmg <dm...@uv...> - 2011-02-17 23:03:07
|
Thanks Jim. I'll check later tonight. Have you been able to discover what we need to support 16 bit layers? I am very interested in that feature and I do what is needed to implement it. --dmg On Thu, Feb 17, 2011 at 2:58 PM, Jim Watters <jwa...@ph...> wrote: > On 2011-02-14 8:46 AM, dmg wrote: >> Hi Jim, >> >> I spent some time tonight reading the spec. It seems that only some >> fields can be "64" or "32" based on the bBig flag. I think it would >> be a good idea to use a macro that is only used when a variable field >> is expected. It seems that the order of other fields (and their >> occupancy) is the same for both types of files. >> >> --dmg > I have updated the code to use functions instead of the macros. And I created > one function for writing 64or32 and one function for reading 64or32. The write > functions return amount written so they can be concatenated together and the > total used to later write the final size. > > Next step is to create a new function to continuously write the layers. > > -- > Jim Watters > http://photocreations.ca > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: Jim W. <jwa...@ph...> - 2011-02-17 23:39:05
|
On 2011-02-17 7:02 PM, dmg wrote: > Have you been able to discover what we need to support 16 bit layers? > I am very interested in that feature and I do what is needed to implement it. > > --dmg 16bit layers is implemented. You do need a newer version of Photoshop to read them. It was added to Photoshop CS that came out is 2003. There was a check for 16 bit in PTtiff2psd that would down grade to 8 bit, that I changed to a only do if forced by a command line argument. All layers and all channels are the same bit depth. Before CS (Photoshop 7) could read and write a flat 16 bit image (no layers). Another thing to implement is compression for read and write. All of the masks would benefit tremendously by writing using compression. And I think all PSD/B files saved by Photoshop use compression by default. -- Jim Watters http://photocreations.ca |
From: dmg <dm...@uv...> - 2011-02-17 23:43:49
|
On Thu, Feb 17, 2011 at 3:38 PM, Jim Watters <jwa...@ph...> wrote: > On 2011-02-17 7:02 PM, dmg wrote: >> Have you been able to discover what we need to support 16 bit layers? >> I am very interested in that feature and I do what is needed to implement it. >> >> --dmg > 16bit layers is implemented. You do need a newer version of Photoshop to read > them. It was added to Photoshop CS that came out is 2003. Really? Last time I tried, it didn't work, but it was many years ago. I will test it. > There was a check for 16 bit in PTtiff2psd that would down grade to 8 bit, that > I changed to a only do if forced by a command line argument. > > All layers and all channels are the same bit depth. > Before CS (Photoshop 7) could read and write a flat 16 bit image (no layers). > > Another thing to implement is compression for read and write. > All of the masks would benefit tremendously by writing using compression. And I > think all PSD/B files saved by Photoshop use compression by default. I am not too worried about it (this is less important). one can always load and resave the file, if compression is important. --dmg > > -- > Jim Watters > http://photocreations.ca > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: dmg <dm...@uv...> - 2011-02-14 12:47:05
|
Hi Jim, I spent some time tonight reading the spec. It seems that only some fields can be "64" or "32" based on the bBig flag. I think it would be a good idea to use a macro that is only used when a variable field is expected. It seems that the order of other fields (and their occupancy) is the same for both types of files. --dmg On Sun, Feb 13, 2011 at 6:28 PM, dmg <dm...@uv...> wrote: > > The execution paths are almost identical, except for the call to > WRITEINT32 or WRITEINT64. Why not > write a new macro, called WRITEINT that takes the bBig as a flag, so > the code will look like this instead: -- --dmg --- Daniel M. German http://turingmachine.org |
From: Jim W. <jwa...@ph...> - 2011-02-14 12:59:40
|
On 2011-02-14 8:46 AM, dmg wrote: > Hi Jim, > > I spent some time tonight reading the spec. It seems that only some > fields can be "64" or "32" based on the bBig flag. I think it would > be a good idea to use a macro that is only used when a variable field > is expected. It seems that the order of other fields (and their > occupancy) is the same for both types of files. Yes exactly. A new Macro maybe WRITE32or64 because there may be a time we need WRITE16or32. > --dmg > > On Sun, Feb 13, 2011 at 6:28 PM, dmg<dm...@uv...> wrote: >> The execution paths are almost identical, except for the call to >> WRITEINT32 or WRITEINT64. Why not >> write a new macro, called WRITEINT that takes the bBig as a flag, so >> the code will look like this instead: > > -- Jim Watters http://photocreations.ca |