Feature request: use HEIC instead JPEG compression in .PLD

[borgo1971]

I did some tries, and seems that HEIC holds far better quality then JPEG with the same file size... so I think it could be e good idea to add or replace JPEG layer compression, and the ability to save them in .PLD files.

[beiti]

I don't think PhotoLine uses JPEG compression inside the PLD format (except maybe for the preview image). For the main layers it must be something lossless like PNG.
Even if they thought about alternatives, there are certainly more appealing options than HEIC. Maybe a lossless AVIF variant would work. Other than HEIC, it is license free.

[Hoogo]

I don't think PhotoLine uses JPEG compression inside the PLD format (except maybe for the preview image).

Not in general.
It does if the layer comes from Jpg and is unchanged.
Or if you compress the layer with ALT+J

[Herbert123]

I don't think PhotoLine uses JPEG compression inside the PLD format (except maybe for the preview image).

Not in general.
It does if the layer comes from Jpg and is unchanged.
Or if you compress the layer with ALT+J

Huh. I was unaware of the option to JPEG compress a layer directly in PhotoLine that way.

Thanks, learned something new!

[bkh]

PL generally uses png compression in pld files, you can choose the compression used (Preferences → File → PLD), currently, there is PNG fast, PNG strong and uncompressed. I'm not sure that other lossless compression formats offer a definitive advantage, given that many of the layers (masks, adjustment layers) have a very simple layer structure.

As Hoogo wrote, PL uses/stores JPEG data instead if its's available. It would be nice if the same worked for HEIC images (currently, it doesn't) – I didn't try WEBP and similar.

[Hoogo]

I haven't seen many other lossy file formats in the wild,maybe a few WebP. On the other hand: I did not really check what file formats are common today.

I can imagine a "Layout > Image > compress layer" instead of "...Jpeg compression", with the Web Export dialog there. Compressing soft layer masks would be nice: Png is somehat big, Jpg becomes blocky, another algo might be better for that.

[borgo1971]

I can imagine a "Layout > Image > compress layer" instead of "...Jpeg compression", with the Web Export dialog there. Compressing soft layer masks would be nice: Png is somehat big, Jpg becomes blocky, another algo might be better for that.

Exactly. What I meant to ask is to replace or add the ability to compress layers with a more efficient algorithm than JPEG and embed this data in .pld files. HEIC seems to me a big step up from JPEG (and it's not blocky), but if there's something better, so be it.

[shijan]

Note that HEIC on macOS is 8-bit only yet until Apple provide higher bit depth support in future OS versions.
https://discussions.apple.com/thread/251072024

[Martin Huber]

Note that HEIC on macOS is 8-bit only yet until Apple provide higher bit depth support in future OS versions.

IIRC macOS 13 offers a 10-bit import, but export is still limited to 8-bit.

Martin

[JanH]

What I meant to ask is to replace or add the ability to compress layers with a more efficient algorithm than JPEG and embed this data in .pld files.

While of course I wouldn't mind support for additional formats, I'd definitively be against "replace" – JPEG files are simply too ubiquitous, so the ability to directly embed them within a .pld-file without having to recompress them is definitively appreciated (except for some slight gripes about the specific JPEG decoder version currently used by PhotoLine). Plus for reasons of backwards compatibility with old files, support for JPEG-in-PLD couldn't be dropped anyway.

But beyond that, additional/alternative support for other formats would of course be nice (also I suppose if e.g. you've got an Apple device and therefore have lots native HEIC images, which you'd want to be able to directly embed inside a .pld).

Semi-related idea: Beyond regular lossy and lossless modes, JPEG XL has a third mode that allows lossless (!) recompression of existing JPEG data. In theory that could be used as a more efficient storage format for JPEG data inside .pld files. The caveat however being that once you start including support for that kind of thing, you couldn't easily drop it again without breaking any .pld files taking advantage of that new feature, so I can understand wanting to be careful about what kinds of image formats are added directly to the .pld-format.

[Hoogo]

To me it's amazing that file formats are a matter of codes or OS today. And still, Faststone won't show me WebP.

What happened to the plain old libraries?

[shijan]

What happened to the plain old libraries?

There are commercial and open source libraries, but i guess most developers use native OS support and don't want to deal with separate HEIC libraries due licensing fees or open source limitations.

[shijan]

But beyond that, additional/alternative support for other formats would of course be nice (also I suppose if e.g. you've got an Apple device and therefore have lots native HEIC images, which you'd want to be able to directly embed inside a .pld).

Semi-related idea: Beyond regular lossy and lossless modes, JPEG XL has a third mode that allows lossless (!) recompression of existing JPEG data. In theory that could be used as a more efficient storage format for JPEG data inside .pld files. The caveat however being that once you start including support for that kind of thing, you couldn't easily drop it again without breaking any .pld files taking advantage of that new feature, so I can understand wanting to be careful about what kinds of image formats are added directly to the .pld-format.

JPEG XL is extremely slow format when it goes to high megapixel images. I suggested earlier JPEG XR which is also may have lossy and lossless compression and outperforms TIFF ZIP in compression speed and file size https://www.pl32.com/forum3/viewtopic.php?f=3&t=6299 , but as i remember JPEG XR seems can't support Lab color model, and also can't do lossless compression for 32 bits floating point if believe Wiki article. So it it also not a universal option for PLD. I guess the main question here - why change things in PLD if PLD already works very well and use very nice lossless compression? Also there is a risk that changes to PLD specification will produce file incompatible with earlier versions of PhotoLine and with plugins that generate thumbnails in Exporer or Finder.
There are many nice formats and compression options but soon or late any "exotic" format bring you to situation when you want back to "classic" TIFF because it is old simple and compatible with everything.

Real life example - EXR PIZ is a lossless compression magic for low contrast images with Linear gamma. It produce way way smaller file sizes than TIFF ZIP. BUT. But it rebuilds data in some own very special way that saving it to PLD may take extreme amount of time. Also PhotoLine seems keeps original EXR data inside PLD because you can see same extreme slowdown on every Save As... So it is OK to use EXR as external file in placeholder in PLD, but very problematic convert it directly to PLD. Another problem is ICC profile and metadata support inside files. Some apps can read ICC profiles inside EXR files some don't.

[JanH]

JPEG XL is extremely slow format when it goes to high megapixel images.

True, good point. Thanks for the reminder.

[Hoogo]

...there is a risk that changes to PLD specification will produce file incompatible with earlier versions of PhotoLine and with plugins that generate thumbnails in Exporer or Finder.

Same risk once applied to 32Bit layers, new adjustment layers, placeholder, distortion... And I'm pretty sure that anything producing thumbnails will just pick the thumbnail stored in the .pld.

...Also PhotoLine seems keeps original EXR data inside PLD because you can see same extreme slowdown on every Save As...

Not sure if we're talking about the same topic...

In the layer attributes you may find an entry "pic. data", followed by either .Png or .Jpg. That means the compressed data for this layer is kept in the background until the layer is changed. That can save the time for a recompression (if you save as Pld), or in some special case of a a simple Jpg, it might save the better original data if it's smaller than the requested compression result.

I checked an example of exr from here, https://github.com/AcademySoftwareFound ... t.0001.exr , and PL does not store some "Pic. data". Imho the request is not about dropping png and jpg, but adding some more formats.

I asked a friend. PDF has a jpxdecode filter, based on jpg2000. So maybe adding such pic data would be beneficial anyways.