1 bit TIFF/Bitmap support please

[loukash]

2 minutes ago, BennyD said:

If you place an 1 Bit image into Publisher, no matter what you do, it will be converted to a 8 Bit greyscale image.

Hm… does it make a difference on the print result?

[BennyD]

19 minutes ago, loukash said:

Hm… does it make a difference on the print result?

Yes it does, specifically for comic lineart if you use 1200 PPI 1-Bit Tifs instead of 300 PPI 8-Bit images.
Original post and explanations here: 

https://forum.affinity.serif.com/index.php?/topic/23232-1bit-bitmap-mode-colour-format/

 

[loukash]

2 minutes ago, BennyD said:

lineart if you use 1200 PPI 1-Bit Tifs instead of 300 PPI 8-Bit images

I know how 1-bit 1200 ppi is supposed to behave.
My question was if the printed artwork is any different when placing the 1-bit TIFF in Affinity as "K Only".
If you then export e.g. a PDF/X, the actual spot color plates are correct, as if you'd be using a true 1-bit TIFF. No matter if the embedded bitmap art in the PDF is 1-bit or converted by Affinity to 8-bit.

[loukash]

11 minutes ago, BennyD said:

Original post and explanations here: https://forum.affinity.serif.com/index.php?/topic/23232-1bit-bitmap-mode-colour-format/

Alright, so the file size is the issue?

[BennyD]

1 minute ago, loukash said:

I know how 1-bit 1200 ppi is supposed to behave.
My question was if the printed artwork is any different when placing the 1-bit TIFF in Affinity as "K Only".
If you then export e.g. a PDF/X, the actual spot color plates are correct, as if you'd be using a true 1-bit TIFF. No matter if the embedded bitmap art in the PDF is 1-bit or converted by Affinity to 8-bit.

Haven't really gone so far, because other issues came along as well, e.g. lack of overprint preview and therefore I stopped using AFpub for serious work.

I imagine other problems arise if you want some sort of preview.
Logically 1-Bit means »color or nothing«.  If you use 1-Bit images you don't need to place the lineart for different spot color channels and multiply them which would then mean some sort of transparency reduction. 

It's such a mess…

 

[BennyD]

10 minutes ago, loukash said:

Alright, so the file size is the issue?

that's one reason for example, but not the only

[gunbunny]

5 hours ago, loukash said:

My question was if the printed artwork is any different when placing the 1-bit TIFF in Affinity as "K Only".
If you then export e.g. a PDF/X, the actual spot color plates are correct, as if you'd be using a true 1-bit TIFF. No matter if the embedded bitmap art in the PDF is 1-bit or converted by Affinity to 8-bit.

It’s as simple as this:

1-bit images get processed as linework (along with everything vector.)

8-bit images get processed as continuous tone.

A RIP will render the linework data at the max resolution of the device, and the continuous tone data gets downsampled to 300dpi and halftone screened. Then everything is trapped and output.

So to answer your question: the plates would be wrong. The 1200dpi 8-bit data would get downsampled to 300dpi and added to the CT data, and the trapping would be bad based on that data.

And ”K only” doesn’t address the issue of having a 2-color job, with a scanned signature supposed to output in 1 PMS color and the body copy supposed to output in another PMS color.

Right now I’m lucky that I only have 1-color jobs and can use the PNG workaround. For a true production-worthy product, this is unacceptable.

[telemax]

I was able to get 1 and 2-bit PNG, with Posterise + Gradient Map + PNG export settings. 2-bit.afdesign
This was just out of curiosity, and probably won't help your workflow.

---

---

---

[BennyD]

8 hours ago, gunbunny said:

It’s as simple as this:

1-bit images get processed as linework (along with everything vector.)

8-bit images get processed as continuous tone.

A RIP will render the linework data at the max resolution of the device, and the continuous tone data gets downsampled to 300dpi and halftone screened. Then everything is trapped and output.

So to answer your question: the plates would be wrong. The 1200dpi 8-bit data would get downsampled to 300dpi and added to the CT data, and the trapping would be bad based on that data.

And ”K only” doesn’t address the issue of having a 2-color job, with a scanned signature supposed to output in 1 PMS color and the body copy supposed to output in another PMS color.

Right now I’m lucky that I only have 1-color jobs and can use the PNG workaround. For a true production-worthy product, this is unacceptable.

Perfect! Thanks.

[loukash]

20 hours ago, gunbunny said:

The 1200dpi 8-bit data would get downsampled to 300dpi

You mean the data in the PDF will get downsampled in the RIP?

Because you can export bitmap from Affinity @1200 ppi to PDF. The thing only is that you don't have any separate setting for 8-bit color, 8-bit gray and 1-bit bitmap like it is in the Adobe apps. You have to work around instead by downsampling any placed 8-bit bitmaps like photos to ±300 ppi @ 100 % size beforehand, then exporting everything with the 1200 ppi headroom.

[Lvis]

"I'll be honest here - we will never implement 1bit document support.. However, we would be happy to implement support for *exporting* 1bit TIFF etc. - would that be enough? Thanks, A"

😬😬😬  Hope is a joke!!!!

"Please Affinity, this is the last thing I need to ditch Adobe for good. Thanks."

🙄

[Eamoex]

"we will never implement 1bit document support"

Why? What is the rationale behind this dogma? There is a saying in my mother tongue which says: "Whoever can do more, can do less". In other words, when your software can handle 16-bit, it seems obvious it should handle 1-bit. Isn't it normal for users (and non-users, for that matter) to think that way?

Really curious. I miss 1-bit support quite often.

[Lorox]

1 hour ago, Eamoex said:

In other words, when your software can handle 16-bit, it seems obvious it should handle 1-bit. Isn't it normal for users (and non-users, for that matter) to think that way?

Yes, exactly what I've been thinking... As the 1-bit thing seems so basic (and intuitive) and has proven to be so useful in everyday design jobs (over years of usage in InDesign back in the day) I really don't get it why the guys at Serif seem so adamant of not implementing proper support in the Affinity apps.

To be honest: as to my current typical jobs I've generally been able so far to get away with that PNG K-only thing, but knowing there have been ways to use 1-bit bitmap properly and to the benefit of users for decades now it feels more than a bit odd to have find workarounds in modern software which (in many respects rightfully and successfully) challenges the industry master(s) of the past...

[Eamoex]

12 hours ago, Lorox said:

has proven to be so useful in everyday design jobs

It's easy for someone who never needed 1-bit depth to overlook just how incredibly powerful, practical and ubiquitous 1-bit images are. Affinity should support that in, out and through.

It is quite literally "digital imaging 101".

Edited March 12, 2024 by Eamoex

[eWalthert]

I was put on this tread from another one that I just started. 

Yes for 1-bit export! Or finally implement a autotracer.
Actually, 1+ for both!

[Lorox]

I still do think 1-bit TIFF support (like we used to have in InDesign or – back in the day – in FreeHand) would be a nice and helpful thing to have. However, with a bit of hindsight I’d like to add that with recent designs/projects (even those basically being updates/redesigns based on IDML-files out of InDesign) switching to grayscale PNGs (using Affinity’s "K only" option) has worked pretty well.

Of course, if you're working on a legacy file (like an IDML from InDesign) that has them, you'll have to convert your original 1-bit TIFFS to grayscale PNGs having just black pixels on a transparent background. Bu this is actually just a matter of seconds in Affinity Photo.

When you leave everything else (size and resolution) as it was you'll then just have to "relink" the original 1-bit-TIFFs in your file via the Resource Manager to the new transparent PNGs (or by ”Replace Image" in the context bar) and you are good to go.

At least this has so far worked fine for me...

[eWalthert]

Dear Lorox, sure, one can work without bitmaps if one only needs the transparency to be applied.

But it does not solve the issue of rasterisation. For everyone working in high quality print, this must be evident.
Please look at the example I shared in this other thread:

 

[Lorox]

3 minutes ago, eWalthert said:

But it does not solve the issue of rasterisation

Ah, sure… you're right. I completely forgot about that. So the PNGs will actually/generally be rasterized to the global resolution as set in the file properties dialog, whereas 1-bit-TIFFs as we knew (and loved) them by default had kept their "own" resolution as defined by their file and – possibly – their scaling in the layout.

BUT: wouldn’t it be some sort of solution to just turn off the downsampling of images with a resolution above a certain value in the Export dialog? (Given you don't have any other "normal" big images which then would be left way too big in the PDF). My 1-bit-TIFFs in the InDesign days used to be about 1200dpi factual resolution as placed and (possibly) scaled in the layout file, which has generally been sufficient and not caused them to be perceived as jaggy when being looked at in a "normal" way.

As to rasterization: I think back ih  the day I've learned that actually ALL content in PDF gets rasterized eventually, albeit to the maximum resolution the RIP is putting out, which then used to be around 2450dpi. So anything with a resolution above that will be sort of downsampled anyway... (meaning, too, that in the printed result you cannot really see a difference between vector curve and a curve from a 2400dpi 1-bit-TIFF). Or am I getting something really wrong here?

[eWalthert]

I guess, that would have to be tested.
I’m still suspecting the RIP to rasterize them like it does with grayscale images.
A grayscale photograph with 600dpi and one with 300dpi will still end up getting the same lpi in the output. Right?

[Lorox]

1 hour ago, eWalthert said:

A grayscale photograph with 600dpi and one with 300dpi will still end up getting the same lpi in the output. Right?

As far as I see it – and with my settings for print production PDFs – the 300dpi grayscale photo image will be rastered at its original 300dpi (thus using its full visual information) and the 600dpi image (assumed to also appear at 100 scaling in the layout) will be rastered for output at 375dpi (as that is the threshold set in my PDF for print export setting beyond which images will be downsampled). Obviously some of the information present in the original 600dpi version that's originally been placed in the layout file will be lost in the process.

However, as raster dots for a given print raster (say like the standard 60 lines per cm) can only have a certain number of "atomic" dots that are no more divisible (dependent on the RIPs resolution) and in relation to the chosen line density can only display/convey a certain range of tone (shades of Black with grayscale images) it is only natural that with an "oversized" grayscale image’s resolution the visual information present in that image can only partially be transported to the final print anyway.

Accordingly there is a natural threshold of the (factual) resolution of grayscale and colour images which, when surpassed, will no longer yield any visible advantage/improvement of the quality of the final printed image.

Also, finer rasters (say 120 lines per cm) are having smaller dots with less tone range, but there will be more of them in an area of fixed size as they are packed more densely – the smallest possible "dot" will be either black or white/nothing (i.e. having only 2 possible tonal values). With 1-bit-TIFFs – as far as I know – there used to be no line raster imposed over their internal pixel raster so any their pixels get assigned directly to a certain number/array of the pixels in the RIP's natural raster either as full ON (> Black) or OFF (>White/Transparent) – according to their position.

I hope I haven't forgotten too much of what I used to learn about this (or tried to, at least…), but it's been quite a while since then. So anybody who might know better is certainly welcome to add his or her – possibly more present day – expertise…

[eWalthert]

I did not mean to start a pissing contest. But it’s the internet, what did I expect?

All you are saying seems right, but does not answer my grievance.
It is not about, if images will be downsampled but about how.
A sharp bit-1 tiff will look better in offset or on 300 or 600 dpi laser printer.

Below are three versions of the same 1200dpi image:
1) 1-bit printed from InDesign
2) 8-bit after opening and saving with same format from Affinity (on the same sheet of paper)
    Since it is not 1-bit, it will always be rasterized to the resolution of the output meidum.
3) same image printed from Affinity Publisher, which is even worse.

I would like to have a possibility to not have it rasterized, because it looks bad and does not need to be.
Another possibility would be to finally implement the much requested auto-tracing function into Affinity.

[Oufti]

3 hours ago, Lorox said:

[…] the smallest possible "dot" will be either black or white/nothing (i.e. having only 2 possible tonal values). With 1-bit-TIFFs – as far as I know – there used to be no line raster imposed over their internal pixel raster so any their pixels get assigned directly to a certain number/array of the pixels in the RIP's natural raster either as full ON (> Black) or OFF (>White/Transparent) – according to their position.

That's the reason why BW images (1-bit) should be placed at the same resolution that the output device can achieve, so there is a direct correspondence between pixels and ink dots.

But if an image is set in 8-bits, it will be "screened" anyway — and some softwares don't do it neatly. 

6 hours ago, Lorox said:

[…] wouldn’t it be some sort of solution to just turn off the downsampling of images with a resolution above a certain value in the Export dialog?

This is a very enlarged example a friend made some years ago of a text set as contone in Photoshop, directly saved from its professional RIP as it was actually "printed" on plates:
Whatever the resolution chosen, Photoshop (or the RIP?) was unable to crop the screen cells neatly on the letter outer path (the thin red line added for reference), resulting in a blurry text, even at maximum resolutions…   

[kafelatte]

On 10/16/2020 at 4:45 PM, gunbunny said:

I'm going to go ahead and +1 this topic.

I started in prepress-land in the mid-90's. And I can tell you unequivocally that 1-bit TIFF support is crucial for production purposes.

First, there is the need for "copy-dot" operations where you have a halftone that you don't want to rescreen. You'd scan this at 100% at a resolution of at least 1200dpi, but preferably 2400-4800dpi. When saved as a bitmap 1-bit TIFF, it outputs at the max resolution of the output device and is not rescreened, and hence, no moire pattern.

Second, and similar to the First, is doing a "copy-dot" on engravings and lithographs. Again, you want those fine detail lines output at crazy-high resolution and not screened.

Third, there is the need for "line art" illustrations. Again, once scanned at a high dpi and placed in the page layout or illustration program as a 1-bit TIFF, it outputs at the max resolution of the device. This yields nice, razor-crisp illustrations for things like instruction manuals, B&W catalogs, and cartoons.

Fourth... this is a curve ball... there was a program waaaaaay back in the MacOS 8 days that I've never seen replicated. (And the name of which I can't remember.) You'd import your 1-bit TIFF, then you could colorize it: either paint the black or else "color inside the lines" in solid colors. It would then be saved as an EPS that would output at... you guessed it... the max resolution of the output device. It was phenomenal for super-crisp catalog work where you are given a hand-drawn lineart that needs colorized, not vectorized. (An example)

Regardless, 1-bit TIFFs, when exporting as a PDF, the data becomes part of the vector data, as opposed to raster data, even though it's technically raster data. The RIP then processes it as part of the line file and it isn't halftoned (unless, of course, it's set to a tint of a spot color, or a CMYK color.) Either way, it's still output at ultra-high resolution. Which is the point. 

Bottom line, this is a crucial missing feature in Affinity Photo, and I sure do hope that it's addressed sooner rather than later.

I brought up this topic yesterday, and was happy to find this post today. I was a print production expert in the early 90s too! I did a lot with digital imagery manipulation for special print processes (CMYK is just so boring). We had our own film imaging system so that we could give perfect films to our printers to work with. Unlimited budget too!

I wish my eyes were as good now as they were then. I could eyeball the output and tell the tech, "the output settings are wrong; I can see that this is only 1270 dpi, not 2540, and the flatness setting isn't right either". Ah, the good old days. 

[Eamoex]

Having to resort to re-saving the image in IrfanView with RLE compression is totally lame. 1-bit TIF should be part of a program like Affinity, no questions asked. I don't understand.

[Lorox]

1 hour ago, Eamoex said:

1-bit TIF should be part of a program like Affinity, no questions asked

Although I've meanwhile adopted some workarounds which sort of do the job for me most of the time, I'd rather agree: 1-bit TIFF is such a basic image format in prepress surroundings that Serif's "stubborn" resistance to add support for it to their apps is really annoying.

And being forced to resave existing 1-bit TIFFs in another format to be able to keep using the image somehow isn't exactly funny.