💡 About TIFF and JPG-XL formats

[Cicorione]

Hi Patrick,

in the manual you stated the only image formats supported are PDF, PNG and JPG.

This really surprised me, PDF are fine however are a mess with different versions and multiple specifications, perhaps embedding a PDF into another PDF is trivial; PNG is not very suited for printing purposes as its acronym states: Portable Network Graphics; JPG is fine but limited.

I wonder why you don't support TIFF images which have been a standard in the printing industry for ages... 🤔

Anyway TIFF is old and newer formats are arising in fact I am looking toward to JPEG-XL to store our catalog pictures, although none of our current software support it but GIMP; having full support for JPEG-XL on Speedata would be a great feature; I don't care if Photoshop doesn't handle JPEG-XL files yet, I can convert all my pictures in flat tiff with transparency and use Imagemagick to convert all of them in jxl.

I don't live closed inside the Adobe walled garden, I really don't care about Adobe software limitations.

[pgundlach]

The backend I use (LuaTeX) is limited to PNG, PDF and JPG. Therefore the speedata Publisher might never support any other image types. You could define a handler that converts these image on the fly with imagemagick, but I believe it would be better to convert these images before hand.

Regarding TIFF: as I understand TIFF is only a container format which can include different kinds of image types and there were so many problems with TIFF files so the backend maintainers dropped support for it.

I always suggest to convert images to PDF if possible. They will be included as-is, all color profiles etc. will be in the final PDF.

[Cicorione]

Oh I see...

By any chance are you involved into the LuaTex project as well?

I searched across their mailing lists and it looks like the jpeg-xl argument hasn't been ever touch.

PDF compression is unfortunately lossy, and PDF generated by Photoshop are bigger than the Photoshop files itself.

I made some test and jpeg-xl is very worthy, look at the specification:

http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

Perhaps I should ask on the mailing list and see what happens... 🤔

[pgundlach]

PDF compression is not lossy! It depends on the software that writes the PDF. Regarding jpeg-xl: I doubt that this is supported by the PDF standard. Do you have any PDF as an example that contains jpeg-xl?

[Cicorione]

Hi Patrick,

sorry for mixing stuff without clarification.

When it is time to embed images into a PDF from the Adobe products your options for compression are mainly jpeg(2000) lossy or ZIP (lossy and loseless), but the latter loseless is very ineffective with pictures.

AFAIK you can't embed any jpeg-xl into a PDF yet, however many designers are pushing Adobe for a full jpeg-xl support. The good news is that recently Apple decided to support jpeg-xl in Safari (just to annoy Google) and this can change the game, and perhaps Adobe will be forced to please theirs customers rather than Google.

Anyway would be interesting having full support for it in LuaTex. I noticed that LuaTeX is very tight to ConTeXt perhaps they are going to be interested in adopting this emerging format...

[pgundlach]

I doubt that I will see jpeg-xl in PDF while I am still alive... The few graphics formats that PDF is able to work with have been there from the beginning (not so sure about jpeg 2000). And the current PDF spec is not developed by Adobe anymore. And even if jpeg-xl is in the spec, the rendering devices will have to support those. And all the commercial printing devices out there with the built in PDF software will probably not get updates for that.

In theory I could extend the speedata Publisher to include other image formats (as long as they are either bitmap formats or jepg/jpeg2000), but it might be much easier to use imagemagick or some other software for the conversion and define an imagehandler to support the automatic conversion. (See https://doc.speedata.de/publisher/en/images/#_external_conversion_tools)

[Cicorione]

I guess you're right! Better using the conversion handler... however I had better to do some test to see how good is able imagemagick to handle conversion between jpeg-xl and pdf.

My concern is more to store pictures at the maximum quality with the maximum compression. A lot of people repeat that storage is cheaper today but mostly do not understand that a for a company without an internal IT department, sometimes even getting a new drive requires months and a lot of coordination, and we produce tons of pictures weekly.

[pgundlach]

My concern is more to store pictures at the maximum quality with the maximum compression. A lot of people repeat that storage is cheaper today but mostly do not understand that a for a company without an internal IT department, sometimes even getting a new drive requires months and a lot of coordination, and we produce tons of pictures weekly.

There are two options (IMO)

1. convert all the images in advance. This is much quicker during the typesetting runs, but costs much more space on the harddrive
2. use the image handler and convert on the fly. Much slower, but less disk space (I have to look up if they are cached, so the speed is only a problem for the first use)
3. (oh, third option) use a digital asset management solution to store images and serve them in different formats/resolutions via http. This might be something between 1 and 2 but maybe overkill in most situations.

So I think you have to pick one of those solutions (or have another good idea and tell me).