Re: [Gimp-developer] [Fwd: Gimp PSD plugin - SEGV when opening files]

2002-01-18 Thread Marco Nierlich

Adam D. Moss wrote:
 Hi guys and gals,

 Could someone with a good collection of .psd files please
 test this against the PSD plugin to make sure it doesn't
 break anything that was not broken before, and if it
 checks out okay commit it to 1.2 and 1.3?  I'm afraid I
 don't have the time for GIMPy stuff at the moment to test
 it myself.

 Cheers,
 --Adam

Hi,

I just downloaded the whole source tree of gimp-1.2.2, patched the psd plugin 
and built the tree. Now, when copying the built psd to 
/usr/lib/gimp/1.2/plug-ins I get an error when starting gimp and PSD files 
don't get opened at all (unknown file type). I do not want to overwrite my 
installed gimp with the freshly built. Is it possible just to replace the psd 
plugin? Maybe someone can send me the build psd plugin for linux with an 
instruction on how to replace the file.

TIA
Marco
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



(psd plug-in, adam's plug-ins) Re: [Gimp-developer] [Fwd: Gimp PSD plugin - SEGV when opening files]

2002-01-18 Thread Adam D. Moss

(CC:ing gimp-developer)

Hi Avi!  'Testing' just involves getting a reasonably
sized collection of PSD files with a good mix of 'real
world' data and more unusual stuff (various aux channels,
layer masks, strange layer modes, strange pixel formats)
and seeing in what ways the PSD loader barfs.  A 'good'
patch is one that allows a greater number of these
files to be successfully read without breaking the
reading of files which were previously readable.

I don't have the (time) resources currently to support
any of my plugins in terms of testing/applying patches
or looking into error reports.  The former should go to
gimp-developer and the latter into bugzilla.  My name
should probably be commented-out from the MAINTAINERS file
until my time situation improves (which seems unlikely
for a while).

Regards,
--Adam

Avi Bercovich wrote:
 Adam D. Moss wrote:
  Hi guys and gals,
 
  Could someone with a good collection of .psd files please
  test this against the PSD plugin to make sure it doesn't
  break anything that was not broken before, and if it
  checks out okay commit it to 1.2 and 1.3?  I'm afraid I
  don't have the time for GIMPy stuff at the moment to test
  it myself.
 
 Hi Adam,
 
 I'd like to help testing anything related to the psd plug-in, because my
 projectleads are breathing down my neck about 'incompatibility' with the
 rest of my designer collegues. I generally use the previous
 state/version of the plug-in that I patch with the 'write psd' patch, as
 I need to send layered files back to people using Photoshop. Let me know
 if/how you'd like me to go about testing the plug-in.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] [Fwd: Gimp PSD plugin - SEGV when opening files]

2002-01-17 Thread Adam D. Moss

Hi guys and gals,

Could someone with a good collection of .psd files please
test this against the PSD plugin to make sure it doesn't
break anything that was not broken before, and if it
checks out okay commit it to 1.2 and 1.3?  I'm afraid I
don't have the time for GIMPy stuff at the moment to test
it myself.

Cheers,
--Adam
-- 
Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/   co:3

all cake everywhere has died
---BeginMessage---

Dear  Adam D. Moss (PSD plugin maintainer)

Attached is a set of context diffs for a work-around for an issue with psd.c
(PSD Plugin version 2.0.6) and PSD files generated by PanoTools. The problem
was reported by Marco Nierlich [EMAIL PROTECTED] in the
comp.graphics.apps.gimp newsgroup, and he supplied a sample of a problem image
http://home.nierlich.org/avifile/pano_psd.psd

I think that the possible problems are:
1) no layermask data
2) the resize_mask() function introduces a 1 pixel down-right shift
3) The RGBA channels arrive in an unexpected order
4) some confusion (probably on my part) about 4-layer (RGB + mask) files
   and when to add the mask layer

PS: I have not got a full copy Photoshop so I may have broken the opening of
some photoshop files without realising it. I think that having applied the fix,
some files generqated by PhotoShop 6 may get their masks incorrectly set when
loaded into Gimp. It also seems quite possible that PanoTools might be
generating invalid files - but without a full copy of Photoshop I cannot
test this.

-- 
Regards
Andy Wallis

==
Andy WallisEmail:  [EMAIL PROTECTED]
Shillito and Company   Web:  http://www.shillito.co.uk
==


*** psd.c.STD   Thu Jan 17 10:08:58 2002
--- psd.c   Thu Jan 17 10:08:55 2002
***
*** 130,135 
--- 130,141 
  
  /* *** USER DEFINES *** */
  
+ /* set to TRUE if you want Andy Wallis fixes for reading files from PanoTools, FALSE 
+otherwise.
+  * There is probably a better way of fixing the problem. Note that these fixes are 
+not tested
+  * against files from Photoshop apart from a few Photoshop 4.0 LE files and may 
+cause problems
+  * with files from more recent versions of Photoshop */
+ #define AFW_FIXES TRUE
+ 
  /* set to TRUE if you want debugging, FALSE otherwise */
  #define PSD_DEBUG FALSE
  
***
*** 1068,1073 
--- 1074,1090 
/*  throwchunk(layermaskdatasize, fd, layer mask data throw);
(*offset) += layermaskdatasize;*/
  }
+ #if AFW_FIXES
+   /* If no layermask data - set offset and size from layer data */
+   if(!layermaskdatasize) {
+ IFDBG
+   fprintf(stderr, Setting layer mask data layer\n);
+   psd_image.layer[layernum].lm_x = psd_image.layer[layernum].x;
+   psd_image.layer[layernum].lm_y = psd_image.layer[layernum].y;
+   psd_image.layer[layernum].lm_width =  psd_image.layer[layernum].width;
+   psd_image.layer[layernum].lm_height = psd_image.layer[layernum].height;
+ }
+ #endif
  
  
layerrangesdatasize = getglong(fd, layer ranges data size);
***
*** 1473,1479 
printf(NULL channel - eep!);
return NULL;
  }
- 
rtn = xmalloc(numpix * 3);
  
for (i=0; inumpix; i++)
--- 1490,1495 
***
*** 1693,1700 
--- 1709,1722 
  {
for (x=0; xdest_w; x++)
{
+ #if AFW_FIXES
+ /* Avoid a 1-pixel border top-left */
+ if ((x=src_x)  (xsrc_x+src_w) 
+ (y=src_y)  (ysrc_y+src_h))
+ #else
  if ((xsrc_x)  (xsrc_x+src_w) 
  (ysrc_y)  (ysrc_y+src_h))
+ #endif
{
  dest[dest_w * y + x] =
src[src_w * (y-src_y) + (x-src_x)];
***
*** 1726,1731 
--- 1748,1758 
gint32 iter;
fpos_t tmpfpos;
  
+ #if AFW_FIXES
+   gint32 mask_id = -1;/* ie not set */
+   int red_chan, grn_chan, blu_chan, alpha_chan, ichan;
+ #endif
+ 
IFDBG printf(--- %s -\n,name);
  
name_buf = g_strdup_printf( _(Loading %s:), name);
***
*** 1848,1853 
--- 1875,1911 
seek_to_and_unpack_pixeldata(fd, lnum, 1);
seek_to_and_unpack_pixeldata(fd, lnum, 2);
seek_to_and_unpack_pixeldata(fd, lnum, 3);
+ #if AFW_FIXES
+   /* Fix for unexpected layer data order for files from PS files 
+created by PanoTools. Rather
+* than assuming an order, we find the actual order.
+*/
+   
+   red_chan = grn_chan = blu_chan = alpha_chan = -1;
+ 
+   for(ichan=0; ichannumc; ichan++) {
+ switch(psd_image.layer[lnum].channel[ichan].type) {
+  case 0: red_chan = ichan; break;
+  case 1: grn_chan = ichan; break;
+