Mike Chaney's Tech Corner
November 17, 2024, 04:38:01 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Qimage registration expired? New lifetime licenses are only $59.99!
 
   Home   Help Login Register  
Pages: 1 [2]
  Print  
Author Topic: transparent borders - Absolute Colorimetric rendering  (Read 16974 times)
StephenG
Newbie
*
Posts: 16


Email
« Reply #15 on: March 30, 2018, 11:15:13 AM »

Thanks Ernst. Spectrumviz has been very useful to me over the past few years, but I didn't know about the Lab values! Not paying attention, I guess.

Hahnemühle is readily available so I'm going to see if I can get hold of some PhotoRag Ultrasmooth. It seems to fit the bill.
Logged
StephenG
Newbie
*
Posts: 16


Email
« Reply #16 on: April 06, 2018, 09:08:01 AM »

OK, finally got a chance to test how well the borders worked, as suggested above. Let the inked borders print and then trim right down to the edges of the borders. It works! And under a variety of light sources too - daylight, solux 4700k, tungsten 2800k. It does a pretty good job of neutralizing the white of the warm paper I'm using. The trouble is that it is reliant on your eyes adjusting to the white of the print. If you look away to a different light source, and then look back to the print, for a second or so the print has a blue-ish border until your eyes adjust again. I'll keep using borders without any inking, as it seems to be more consistent. It is also consistent with prints previously produced.

The template border trick: I tried it again this morning and hit a snag. I set the print size to 380x290mmmm and placed an image in the workspace. I set the layout to Template Centered. Then I set the new working size to 446x366mm. Then I selected a dashed line under Cut Marks. Then I shifted the print up a few mm to give the bottom border a bit more space. Then I printed.

The print came out accurately at 380x290mm but the dashed line printed at 445x362mm. 4mm less than specified.

At the moment I can't use this template work-around. I repeat my request, if it's possible, for a transparent border option. This will also enable me to print different sized prints in the same layout, which is not possible with the work-around.
Logged
admin
Administrator
Forum Superhero
*****
Posts: 4218



Email
« Reply #17 on: April 06, 2018, 11:20:02 AM »

OK, finally got a chance to test how well the borders worked, as suggested above. Let the inked borders print and then trim right down to the edges of the borders. It works! And under a variety of light sources too - daylight, solux 4700k, tungsten 2800k. It does a pretty good job of neutralizing the white of the warm paper I'm using. The trouble is that it is reliant on your eyes adjusting to the white of the print. If you look away to a different light source, and then look back to the print, for a second or so the print has a blue-ish border until your eyes adjust again. I'll keep using borders without any inking, as it seems to be more consistent. It is also consistent with prints previously produced.

I could add a spacing (transparent) border but...

If you print the borders with no ink, the opposite is true: as you are looking at the print, your eyes adjust to the border which is paper white so any white in your photo is going to look bluish.  In addition, even the colors in the photo will be shifted a bit toward blue.  If you are printing with a paper white border, you should really be printing with relative colorimetric intent.  Have you printed with relative colorimetric and absolute colorimetric and compared them?  I'm curious as to what you see that is making you print absolute colorimetric.  In addition, and I didn't point this out before, but your white shift (that bluish tint) is a far greater shift in white than I have ever seen on any paper using AC intent.  With every paper I have ever tested (even third party papers), the white shift is so subtle that you can't even pick it up with your eyes: you have to use magnification to even tell there is any ink laid on the paper.  Yes, if you look at the print before cutting it, you can tell that the border is a slightly different shade but it typically only looks like a different shade of white: usually just a little bit more gray than white, not blue, red, or any color tint.  So that has me questioning your profile to begin with, or maybe the paper if you are truly printing on paper with that much of a yellowish or redish cast that it needs that much correction to make it neutral.

Mike
« Last Edit: April 06, 2018, 11:38:26 AM by admin » Logged
StephenG
Newbie
*
Posts: 16


Email
« Reply #18 on: April 10, 2018, 08:22:47 AM »

Yes, the effect does work the other way too, but for some reason it's not as pronounced.

For the last 7 years I've been using Relative almost exclusively and have only recently started experimenting with Absolute rendering. Relative works most of the time but the whitepoint shift affects all the lighter colours and I tend to loose out on light blues when I print on warm paper. I also fight against BPC, which lightens the blacks/deep shadows a bit too much. I need to have both rendering intents as options and it would be really good if I could use the same workflow for both. I prefer to have no ink in the borders when I use Absolute so I really would appreciate having a transparent border option.

I have other papers but for this discussion I'm working with Epson Cold Press Natural. One of the warmer papers out there so it's going to need a significant amount of blue to neutralize it. Profiled carefully by myself through i1Profiler. White point set to paper white point. All you've seen so far is my screengrab of an Epson Print Preview on a wide-gamut screen. The previews are not colour-managed and are usually very over-saturated. The border doesn't print as blue as it looks in the screengrab.
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Security updates 2022 by ddisoftware, Inc.