Jump to content
You must now use your email address to sign in [click for more info] ×

1 bit TIFF/Bitmap support please


Recommended Posts

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?

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

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.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

11 minutes ago, BennyD said:

Alright, so the file size is the issue?

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

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…


 

___♥___
| | |    | | |

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

2-bit_Export.png.e9b2b27e7d428c7cabae03aa498e4cae.png

---

1-bit.png.20d408f51ed0a1e9ba50ed192fd8d4b0.png

---

2-bit.png.2f63c1e79cf5d6710f3635640c017888.png

---

Link to comment
Share on other sites

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.

___♥___
| | |    | | |

Link to comment
Share on other sites

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.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

  • 1 month later...

"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."

🙄

Link to comment
Share on other sites

  • 2 years later...

"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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 by Eamoex
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.