I was able to find this link http://www.telegraphics.com.au/svn/psdparse/trunk/psd_zip.c and if this library works well with PSD/PSB files with compressed(zip) image data, then it is possible to use Qt's qUncompress() function since it uses zlib. Can't test it since I don't have an image file with this kind of compression, neither I can save an image in Photoshop with such compression - I am not an expert (yet) of the software.

I'd like to package libqpsd for Arch Linux (needed for nomacs - at least most likely in the future).
Sadly, using qmake is a nightmare...

Currently, I'm trying something in the vein of:

mkdir build
cd build  
qmake "QT_INSTALL_PLUGINS=/usr/lib/qt/plugins" ..
make
make DESTDIR="${pkgdir}" install

However, the install target just deletes the .so file and then all fails.
In the end I end up manually placing the .so file into the package file system...
It seems, the .pro file is actually pretty unusable on Linux.
There's no documentation on how to use it, what the variables actually do and what the estimated outcome would be.
Any help on how to procede would be very much appreciated!

It shows a pure white image instead of a correct one.

adobe rgb.zip

As described in the PSD File Format Specification:

"Duotone images: color data contains the duotone specification (the format of which is not documented). Other applications that read Photoshop files can treat a duotone image as a gray image, and just preserve the contents of the duotone information when reading and writing the file."

I do understand how duotones are created, the only problem is the structure of the file (and possible computation) which is not readily available. Anybody who tried to deal with duotones (monotone, duotone, tritone, quadtone)? Or possible links, sites, resources, etc. will be a big help.

Hi!

I was able to obtain a copy of a PSB file from a Qt-Project username "asgohtals" (http://qt-project.org/forums/viewthread/22179/) in Lab color mode (with alpha color, aLab) and found out that the alpha channel is somewhat inverted (opaque = 0 and transparent = 255). I also found the reason why the Lab-to-RGB conversion algorithm cannot convert few pixels correctly since the calculated RGB falls outside the range 0-255.

Although libqpsd was able to render the image, there is a big discrepancy in color as shown in this screenshot (https://www.dropbox.com/s/3rbpkm5ddyrvcse/color%20difference.PNG). The image shown in photoshop software was sharper than the image rendered in a Qt-based image viewer I created.

It would be awesome, if libqpsd could have more frequent releases (through tags).
There are some major improvements since the last (and currently only) version tagged.

For distribution package maintainers this is very valuable, as libqpsd is a dependency for nomacs and it would be very good to finally be able to actually use the distribution's libqpsd version, when building nomacs.

Thanks for your work!

I have some psd file with transparency background. I try load it with libqpsd, but some pixels with opacity displays incorrect:

Left - psd file, loaded with libqsd, right - png file saved from same psd file using photoshop.
Psd file format: RGB color, 8-bits per channel, Photoshop CS5.
Same thing has in all my psd files having non-white transparent pixels.

I am having problem converting 32-bit depth into 8-bit depth. It seems that I can get the image's "silhouette" using the formula
value_8bit = value_32bit * (qPow (2, 8) - 1) / (qPow(2, 32) - 1)

But if I multiply it again with (qPow (2,8) -1) or 255, the image is almost close, at least at "grayscale" mode. I can't find any references on the conversion.

When I load this file, app would crash.

https://drive.google.com/file/d/0BxUO3KDi7ZfydjBhYlJPTURDcjg/view?usp=sharing

How to avoid this?

Hi,

I am working on bringing this library to Debian. However, the library does not set SONAME. Please help to set SONAME so that we can handle the dependencies more easily.