Add PSD export example

[andersmelander]

The code needs to be cleaned up a bit before it can be merged.

I'm also getting the occasional range check error or overflow error when saving PSD.

Initial tests show that some applications have problems reading the generated PSD while others read it fine. This could very well be a problem with the readers and not in the generated files.

[andersmelander]

@lamdalili I can see that the original code (in your repo) is GPL licensed. Graphics32 uses the MPL 1.1 or LGPL 2.1 licenses.
Are you okay with your code being included under the Graphics32 license (i.e. not GPL)?

[lamdalili]

I'm also getting the occasional range check error or overflow error when saving PSD.

I wrote it with the default configuration, if range checking is enabled, errors may occur.

Initial tests show that some applications have problems reading the generated PSD while others read it fine. This could very well be a problem with the readers and not in the generated files.

I think this due to the zip compression which isn't supported by all editors,
in the example change Psd.PsdLayerCompression := psComZip; to psComRLE or save without any comprsesion and see if the error remains,

Are you okay with your code being included under the Graphics32 license (i.e. not GPL)?

yes, no problem for that.

[lamdalili]

I found some range erreurs :
Out8(R - 1); here

graphics32/Examples/Layers/PSD Export/UPSD_Storage.pas

Line 180 in a066eab

Out8(R - 1);

Also the call to Swap needs to be protected when the var is signed SmallInt(Swap ()) inverting bytes order may produce invalid value for this type

[andersmelander]

I think this due to the zip compression which isn't supported by all editors,

Yes, I suspected that much but I think there's more to it.
For example, this online viewer has problems with the ZIP compressions: https://www.fviewer.com/view-psd
It loads them but displays junk in the layers.

While this one handles ZIP but not ZIPrd and complains about an invalid signature with all compressions: https://www.photopea.com/

The PSD reader in GraphicEx refuses to load anything regardless of compression. I have previously used it to load PSD so I know it works.

Anyhow, I believe I have now resolved all the issues regarding range check errors.

[andersmelander]

The PSD reader in GraphicEx refuses to load anything regardless of compression.

It was a bug in GraphicEx; It didn't take alignment padding between adjustment layers (e.g. Unicode layer name) into account. Now it works:

I can see that the GraphicEx PSD reader only supports RAW and RLE compression, so it will need some minor work to be able to support full round-tripping.

[andersmelander]

As far as I can tell we're ready to merge.

[lamdalili]

Great ,I see a lot of progress in the project and a lot of bugs been fixed,
it's a real challenge to make it compatible for all editors. I think it's still doable if opening the file in Photoshop and save new copy and then check the ajusted or added parts this gives idea about default configuration.

While this one handles ZIP but not ZIPrd ..

Actuelly they use the same function, the code for the compression operation was improvised and needs to be rebuilt.

[andersmelander]

While this one handles ZIP but not ZIPrd ..

Actuelly they use the same function, the code for the compression operation was improvised and needs to be rebuilt.

Ah! So it probably does handle ZIPrd but we're not supplying the correct data.
Then I think it would be better to disable that compression type for now.

[lamdalili]

Ah! So it probably does handle ZIPrd but we're not supplying the correct data.

Yes, i dont no idea what's the difference and how it should be implmented.

Can you laod the image in the example as first layer this makes test more random instead of those monolitic shapes with few colors.

[andersmelander]

Yes, i dont no idea what's the difference and how it should be implmented.

Okay, no problem. It can wait for later. This is a great start regardless.

I had a quick look at how it's done in ImageMagick but I don't really have time to do anything with it right now. I also think it has low priority compared to also being able to read PSD files.

[lamdalili]

Another problem, image "or what we call background here" for most editors supports only the RLE compression, that's why I set it permanently in the code, L738, for now Compression has no effect `WriteSwappedWord(FStream, Ord(psComRLE));

const
  FolderMedia = '..\..\..\..\..\Media';

The last commit for loading static jpg doesn't work I 've error "file not found" or some thing like; currently the build output folder isn't configured, and the build is at the same level of poject.

[andersmelander]

Another problem, image "or what we call background here" for most editors supports only the RLE compression, that's why I set it permanently in the code,

Yes, I noticed that. I think it's sensible to have RLE as the default, but since it's possible to specify another compression we really should respect that and use the compression specified.

Anyway, I have begun work on moving your PSD-writer into an image format adapter. I will push some code (into a new branch) for it later today.

The last commit for loading static jpg doesn't work I 've error "file not found" or some thing like; currently the build output folder isn't configured, and the build is at the same level of poject.

That's strange. It should be correctly configured. This is what I'm seeing:

What version of Delphi are you using?

[andersmelander]

That's strange. It should be correctly configured. This is what I'm seeing:

Ah! I've forgotten to push the project settings file. I'll get that committed now.

[lamdalili]

Ah! I've forgotten to push the project settings file. I'll get that committed now.

Thanks it works now.

[lamdalili]

It was a bug in GraphicEx; It didn't take alignment padding between adjustment layers (e.g. Unicode layer name) into account. Now it works:

Maybe, but for Photopea, the problem persists if you append the name by one character, an error message occurs, the problem is when you have two variable aligned sections, you don't know at which one the error happened, by adding null character you just aligned ExtraSection by 4 (the spec accepts alignment by 2 but applications use alignment by 4 ) )

This value should be updated to 4

graphics32/Source/GR32.ImageFormats.PSD.Writer.pas

Line 589 in 89b9c21

WriteEndSection(2);

[andersmelander]

This value should be updated to 4

Please create a pull request and I'll merge it.

[andersmelander]

Maybe, but for Photopea, the problem persists if you append the name by one character, an error message occurs, the problem is when you have two variable aligned sections, you don't know at which one the error happened, by adding null character you just aligned ExtraSection by 4 (the spec accepts alignment by 2 but applications use alignment by 4 ) )

I'm still seeing the same Photopea warning with ZIP-compressed PSDs.

[lamdalili]

Yes I see the error before and I try to understand it, the error happens when Photopea tries to read Layer Glabal Mask which is located just after the LayerInfo section containing the image data, The LayerInfo section is aligned to 2 as shown in the spec, but again needs to be moved to 4 as in the previous case.

graphics32/Source/GR32.ImageFormats.PSD.Writer.pas

Line 712 in 12c9d07

WriteEndSection(2);

spec:

Length of the layers info section, rounded up to a multiple of 2.
https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/#50577409_16000

[andersmelander]

The LayerInfo section is aligned to 2 as shown in the spec, but again needs to be moved to 4 as in the previous case.

Okay. I'm trying that out now... Yes, that did the trick. I'll commit the change.

While comparing the spec to the implementation I noticed this in the description of the Channel image data:

If the layer's size, and therefore the data, is odd, a pad byte will be inserted at the end of the row.

I can't see that we're doing that.

[lamdalili]

I can't see that we're doing that.

I'm not sure understand all, if talking about each channel separately this might cause problem for decoders, otherwise all other sections at this scope are aligned and any misaligned image data will be corrected, if you know how to handle it you can update the code.