Pages: 1 2 [3]   Go Down

Author Topic: Qimage for Mac-Canon Pixma Pro9000 Mk II Printer Settings and Color Management.  (Read 9948 times)

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20648
  • Andrew Rodney
    • http://www.digitaldog.net/

If you think we were, you may want to think of the irony of explaining how something that is undocumented can be considered a guideline!
IF it really were totally undocumented, how did Mark and I know to pass this on to you and others this week how did you end up coding it? This SPI has been around at least 10 years if not more. I've got email from an Apple engineer dating back to 2007 about it. Nothing new. Glad you found it and incorporated into your product. Seems it wasn't 'big engineering' and again, I applaud you for making it so. Again, had someone, somewhere in the past brought the older behavior of your product with respect to picking sRGB, wouldn't this entire thread be moot? Yes and now it is.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

enduser

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 610

Years ago I read Mike's reasoning as to why he'd never develop a Mac version of Qimage. He must have anticipated the attitude problems we're now seeing.
Logged

Ernst Dinkla

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4005

Years ago I read Mike's reasoning as to why he'd never develop a Mac version of Qimage. He must have anticipated the attitude problems we're now seeing.

That reasoning was more based on Apple's cooperation as I recall it. It now looks like Apple users are harder to please than Apple itself :-)

Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots

Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20648
  • Andrew Rodney
    • http://www.digitaldog.net/

It now looks like Apple users are harder to please than Apple itself :-)
If you've ever worked for Apple (yes I have), you'd know that's not true but close! ;D
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Binartem

  • Newbie
  • *
  • Offline Offline
  • Posts: 47

IF it really were totally undocumented, how did Mark and I know to pass this on to you and others this week how did you end up coding it? This SPI has been around at least 10 years if not more. I've got email from an Apple engineer dating back to 2007 about it. Nothing new. Glad you found it and incorporated into your product. Seems it wasn't 'big engineering' and again, I applaud you for making it so. Again, had someone, somewhere in the past brought the older behavior of your product with respect to picking sRGB, wouldn't this entire thread be moot? Yes and now it is.

The whole subject of graying out those controls was moot from the start!  I used the word "undocumented" because you've been using it (and "private") in your own posts for years.  A quick search on Google will prove that:

https://www.google.com/search?q=kPMApplicationColorMatching+private

Now, after referencing your posts on the subject, I should point out that they are not really accurate WRT graying out the color controls since we've been using kPMApplicationColorMatching from the start: that part is public.  kPMApplicationColorMatching is a public/known parameter that you can pass to the driver in order to set Colorsync when you want the application to manage color: we've been doing that all along.  I don't want to go into detail about the private function since it is marked private, but it is not called kPMApplicationColorMatching and the private function is not listed anywhere on google as you'd expect: it's private.  I'm not expecting you to know that since I don't think you're an Apple developer but we figured that out a few months ago which is why we started down the path to obtain the code to do that.  In the mean time (in all versions prior to 106), we've been using kPMApplicationColorMatching per Apple's documentation, simply without using the private function to gray out the controls.  Apple's own documentation indicates that the private function is to be used for specialized purposes and not for general applications.

Hope that will clear things up about using kPMApplicationColorMatching versus using the private function (which I will not name but is not called kPMApplicationColorMatching) to gray out controls.

Regards,
Mike Chaney
Binartem, Inc.
ddisoftware, Inc.
Logged
Binartem, Inc.
ddisoftware, Inc.

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20648
  • Andrew Rodney
    • http://www.digitaldog.net/

Mike, I am not an Apple developer, my two engineers are.
If anything, glad to see the “tough love” comments got your product to implement a better, more intuitive method of setting the CS radio button. No need to find another product that behaved so oddly by asking users to set sRGB, dialogues to instruct them to do so and introduce, as Mark well spoke of (more CMS oddities), conforming to GUI standards and so on. Time well spent above and beyond some OT comments from a few with zero experience developing software who are on my ignore (ignorance) list.

Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

jrsforums

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1288

Mike, I am not an Apple developer, my two engineers are.
If anything, glad to see the “tough love” comments got your product to implement a better, more intuitive method of setting the CS radio button. No need to find another product that behaved so oddly by asking users to set sRGB, dialogues to instruct them to do so and introduce, as Mark well spoke of (more CMS oddities), conforming to GUI standards and so on. Time well spent above and beyond some OT comments from a few with zero experience developing software who are on my ignore (ignorance) list.

Good grief.  You are so impressed with yourself that you do not read what others write.  Your “tough love” had nothing to do with what transpired.  You are much like a current, well known, public figure who things that all good things are the result of his actions and bad things are fake news.
Logged
John

Denis de Gannes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 319

Quote "comments from a few with zero experience developing software who are on my ignore (ignorance) list."

And what is that supposed to mean. :o
Logged
Equip: iMac (Ret. 5K,27"Mid 2015),macOS 10.15.6

jrsforums

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1288

Quote "comments from a few with zero experience developing software who are on my ignore (ignorance) list."

And what is that supposed to mean. :o

Me. 😀

Of course, he has zero info on my experience.  And I have no plans of going down that “rat hole” with the likes of him.  😀
« Last Edit: January 25, 2018, 12:46:43 pm by jrsforums »
Logged
John

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20648
  • Andrew Rodney
    • http://www.digitaldog.net/

Now, after referencing your posts on the subject, I should point out that they are not really accurate WRT graying out the color controls since we've been using kPMApplicationColorMatching from the start: that part is public.  kPMApplicationColorMatching is a public/known parameter that you can pass to the driver in order to set Colorsync when you want the application to manage color: we've been doing that all along.
Better?

Products should be calling:
   PMSessionSetColorMatchingMode(printSession, printSettings, kPMApplicationColorMatching)
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

jrsforums

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1288

Better?

Products should be calling:
   PMSessionSetColorMatchingMode(printSession, printSettings, kPMApplicationColorMatching)

IF that is correct....and IF you knew it from the get-go (doubtful??) why did you not  share it then rather than go through all the BS?
Logged
John

Binartem

  • Newbie
  • *
  • Offline Offline
  • Posts: 47

I feel like we've been around the barn and back chasing a chicken, only to realize we had some in the fridge.  Anyway, hopefully we've all ended up at the same dinner table in the end.  I won't say any more than that as I'm finding it uncomfortable talking about Apple's privates.  ;)

Regards
Logged
Binartem, Inc.
ddisoftware, Inc.

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285

I feel like we've been around the barn and back chasing a chicken, only to realize we had some in the fridge.  Anyway, hopefully we've all ended up at the same dinner table in the end...

Regards
Indeed we did with respect to current Apple color management protocol. "Documented", "undocumented", "private", or whatever, as a Mac enduser of numerous application managed apps on the Mac, all I know is that "typical" no color adjust and even application managed color pipelines on the Mac nowadays invoke a "greyed out" colormatch menu in the printer driver. It's not just adobe or Xrite that follow this protocol. It's Apple itself, and one can clearly see this method displayed in numerous Apple apps like Pages, Numbers, even Apple Colorsync utility. So, it's great that, despite some heated discussion here in this thread, the Qimage software team has now implemented the "greyed out" approach which today's Mac using printmakers have come to know (and love?) on the Mac.

So, Mike, while we have your attention in this thread, may I beseech you personally to prioritize another new feature for Q1. For those of us who routinely print on rolls, how about an auto page length feature like the big expensive RIPS have. That would be a rather unique feature, IMHO, at Q1's price point. By that I mean, when choosing "roll" rather than cut sheet as the media, it would be great to be able to dump a number of files onto the page area and have Q1 calculate how much roll length is needed, then tell the printer to set that page length so as to efficiently print the chosen image or set of images. Right now, I find I have to guess or pre-calculate that length and manually enter it into the custom size field. The roll width is known. That's easy. But the length of paper optimally defined to be just enough to accommodate the images selected for print must now be manually entered by the enduser. Choose too much length and you waste paper.  Choose too little and image "shrink to fit page" starts occurring.

Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20648
  • Andrew Rodney
    • http://www.digitaldog.net/

Indeed we did with respect to current Apple color management protocol. "Documented", "undocumented", "private", or whatever, as a Mac enduser of numerous application managed apps on the Mac, all I know is that "typical" no color adjust and even application managed color pipelines on the Mac nowadays invoke a "greyed out" colormatch menu in the printer driver. It's not just adobe or Xrite that follow this protocol. It's Apple itself, and one can clearly see this method displayed in numerous Apple apps like Pages, Numbers, even Apple Colorsync utility. So, it's great that, despite some heated discussion here in this thread, the Qimage software team has now implemented the "greyed out" approach which today's Mac using printmakers have come to know (and love?) on the Mac.
Well put! Protocols (rules) at least on the Mac OS should be followed.
Joseph Campbell — 'Computers are like Old Testament gods; lots of rules and no mercy.'
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Ernst Dinkla

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4005

For those of us who routinely print on rolls, how about an auto page length feature like the big expensive RIPS have. That would be a rather unique feature, IMHO, at Q1's price point. By that I mean, when choosing "roll" rather than cut sheet as the media, it would be great to be able to dump a number of files onto the page area and have Q1 calculate how much roll length is needed, then tell the printer to set that page length so as to efficiently print the chosen image or set of images. Right now, I find I have to guess or pre-calculate that length and manually enter it into the custom size field. The roll width is known. That's easy. But the length of paper optimally defined to be just enough to accommodate the images selected for print must now be manually entered by the enduser. Choose too much length and you waste paper.  Choose too little and image "shrink to fit page" starts occurring.

Mark,
Qimage Ultimate has a feature "Set paper length" for that. You define and save a very long print page in the driver. Call that size from QU, fill it up with images with Optimal nesting (least paper waste) and right click on the print page preview to let "Set paper length" act, the unfilled part is cropped away. I see even two choices for that there. Not yet implanted in Q1.  BTW it works with most Windows printer drivers but not with the HP Z3200 PCL3 driver, the PS3 driver does it better though. Not all drivers are created equal, that is a rule you will encounter more often with QU.

BTW. when Binartem gets its own Q1 forum I suggest the creation of a wish list there too, like the one I suggested for the QU forum;
http://ddisoftware.com/tech/qimage-ultimate-wish-list/

Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
« Last Edit: January 26, 2018, 03:38:37 am by Ernst Dinkla »
Logged

Binartem

  • Newbie
  • *
  • Offline Offline
  • Posts: 47

So, Mike, while we have your attention in this thread, may I beseech you personally to prioritize another new feature for Q1. For those of us who routinely print on rolls, how about an auto page length feature like the big expensive RIPS have. That would be a rather unique feature, IMHO, at Q1's price point. By that I mean, when choosing "roll" rather than cut sheet as the media, it would be great to be able to dump a number of files onto the page area and have Q1 calculate how much roll length is needed, then tell the printer to set that page length so as to efficiently print the chosen image or set of images. Right now, I find I have to guess or pre-calculate that length and manually enter it into the custom size field. The roll width is known. That's easy. But the length of paper optimally defined to be just enough to accommodate the images selected for print must now be manually entered by the enduser. Choose too much length and you waste paper.  Choose too little and image "shrink to fit page" starts occurring.

We've been taking notes regarding the features that people find most important and I can tell you that auto page length is one of the things we'll be working on.

Regards
Logged
Binartem, Inc.
ddisoftware, Inc.

Abdo

  • Full Member
  • ***
  • Offline Offline
  • Posts: 157
    • Abdo Abdala - Photography

my dream was to be able to have cut marks .. with defined edges.
example: image has 24x24 .. and I want 2 more white margin and appear the marks in 26x26 .. can you understand Mike? ::) ::)

Binartem

  • Newbie
  • *
  • Offline Offline
  • Posts: 47

my dream was to be able to have cut marks .. with defined edges.
example: image has 24x24 .. and I want 2 more white margin and appear the marks in 26x26 .. can you understand Mike? ::) ::)

Sure.  With the initial release, we wanted to concentrate on users being able to easily get high quality prints at any size.  From there, we evaluate the market as to other features (beyond just printing the photos) that help with the photo printing process in general.  People have expressed a need for things like crop marks, guide lines, borders (which gives you the ability to get your margins around prints that you mention for the guides), text such as image info, auto paper length features for roll printing, and so on.  As you can see, many such features are related and we have a plan to implement them in a logical order.  Not all will come at once of course, which is why we are paying attention to what is most important to those who use Qimage One and factoring that into what comes next in each update.

All I can say is... stay tuned.  ;)

Regards
Logged
Binartem, Inc.
ddisoftware, Inc.

Abdo

  • Full Member
  • ***
  • Offline Offline
  • Posts: 157
    • Abdo Abdala - Photography

Thank you ! And I'm sure of your success!

The important thing is not to be fast, but to do with quality!   8) 8)
Pages: 1 2 [3]   Go Up