Mike Chaney's Tech Corner

http://www.ddisoftware.com/qimage-u

v2012.216    03/05/12

Priority: Low

v2012.216 includes the following:

• Process larger files: v2012.216 allows opening very large files: up to 1.5GB and beyond with some compressed formats under Win7 x64.
• Canvas shrinkage compensation: Check the job properties tab for the new canvas shrinkage compensation feature.
• Fix: Fixed a bug where the print properties button was not working on prints that have a mirror edge border.

Mike

Thanks Mike!

  I was intermittantly experiencing the bug also and was about to question why it was happening. hongu123 beat me to it. Thanks for the fix!

As far as the canvas shrinkage adjustment. Will it mostly be a matter of experimentation to get the setting right with individual products ,and then save it as a printer setup? Any guidlines as to where to begin to adjust?
Great feature BTW!!  ;D

Thanks,David

If it also does that on Vista x64 you could not have chosen a better day to bring this upgrade. Have to print 3.5 x 8 feet rainbow pieces on Wednesday. Compressed Tiffs too?


met vriendelijke groeten, Ernst
Try: http://groups.yahoo.com/group/Wide_Inkjet_Printers/

You could probably google it for the printer/paper you are using and find something but it really only takes one test print to figure it out.  Print something and measure the length.  If you print 36" in length and what comes out is actually 35.5 inches, then your shrinkage is 36/35.5 or 1.4%.

Mike

Mike,
My printer stretches every 20" of image to 20.2" of canvas. Just to make sure I understand this, 20.2/20 = 1.01. Thus I would input 1.01 into the shrinkage field and Qimage will vertically scale the images down so that they print to 20"?
Thanks,
Seder

Canvas typically shrinks.  Are you saying yours expands?

Mike

My bad. I meant to say that my printer/canvas shrinks every 20.2" of image to 20" of canvas. Just to make sure I understand this, 20.2/20 = 1.01. Thus I would input 1.01 into the shrinkage field and Qimage will vertically scale the images UP so that a 20" image would print 20"?
Thanks,
Seder

Correct.

Mike

Mike,

No, not correct.

The proper calculation for shrinkage percentage would be

100*((20.2 -20)/20) = 10%

Jim H.

Well, if I'm going to be a smarty pants, I guess I should try to get it right!!!

I meant 1% and not 10%

JimH

I'll get it right yet.

After due consideration and consultation at the highest levels:

The percent change is the change from the intended amount divided by the intended amount times 100.

Therefore the correct answer should be

100*((20.2 - 20)/20.2) = 0.99%

since the intended amount was 20.2 and not 20.

Jim H.

try again, Jim  ;D

Well, since I'm having a conversation with myself, I will continue.

I finally looked at the "Canvas shrinkage compensation" input for Qimage Ultimate.  It says "stretch the length by this amount".  If this is really what is wanted, it seems to me that what we need to be calculating is the percentage to stretch and not the resultant percentage shrinkage from the desired amount.  In that case we would want to stretch from 20 inches (which is what we are getting) to the desired 20.2.  If that is the case, then it seems the proper percentage of stretch would be

100*((20.2 - 20)/20) = 1.0%

I await incoming.

Jim H.

RayW said

"try again, Jim"

Well, I would like to hear more in the way of argument than that.

My main point is that normally when we refer to a percentage change we are not talking about a ratio of intended amount to result but instead to the resultant difference or delta divided by the base value.  In that case, Mike had the correct answer for shrinkage of 35.5 result for 36 intended.  He said the shrinkage is 36/35.5 or 1.4%.  His answer is correct but the method he is suggesting is incorrect.  The proper calculation should be

100*((36 -35.5)/36) - 1.389% which rounds to 1.4%.

36/35.5 = 1.014 on my calculator.

This lead Seder to do 20.2/20 = 1.01% which is clearly wrong.

So, rayw, I would encourage you to "try again".

The only way that I can see that I am incorrect is if the definition of percent stretch is really the ratio and not the usual percent change.  If that is the case then his initial example is wrong.

Jim H.

In my previous post I said

"The only way that I can see that I am incorrect is if the definition of percent stretch is really the ratio and not the usual percent change.  If that is the case then his initial example is wrong."

Just to clarify, what I meant is that I am wrong if Mike intended us to use the ratio in QU instead of the normal definition of percent stretch.  But if this is the case then he is being inconsistent in his first example.

Jim H

Hi Jim,

It's a question of semantics, I guess. Confusion caused between stretching and shrinkage. Usually, in my world, a per unit change (simply multiply by 100 if the per unit value is small to get percentage) is the amount you have to move from where you are to where you want to be expressed as a ratio of where you are. So, if I want to walk ten miles, and I've gone eight, then I have to walk (10-8)/8 of the distance that I've walked so far e.g. 1/4 or 25% more. If I want to look back at it, from the destination, then the last effort was (10-8)/10 or 1/5th or 20% of the total.

So, Mike has said you want to make (that is the destination) a 36 long print, but you get 35.5, so shrinkage is 100x(36-35.5))/36 = 1.3888%, or 1.4% in real money. (you have to stretch what you have by 1.4% to get to the desired length). If you happen to get a print, say 36.5 long, then shrinkage would be 100x(36-36.5)/36 = -1.4%, (call it 1.4% stretch?) and you have to shrink your result by 1.4% to get to where you want to be.

Aternatively, you could say, in the first case (shrinkage) that from where you are, you need to stretch what you have by 100x(36-35.5)/35.5 = 1.4084 (or 1.4%) to get to the desired length, so if the shrinkage is small compared with the length, whether actual or desired, it doesn't really matter which method you use to calculate it, in a practical situation.

Have I confused you yet? If so, do what I do - make the frame to suit the size of the canvas.  :D

I was sort of amused by your discussion with yourself, and wondered how long you could keep doing so  ;)

Best wishes,

Ray

edited to correct typo in calculation

RayW,

Now we are making progress.  I agree with what you are saying regarding percent change, but


I would say it's more a matter of precise definition on Mike's part than one of semantics.  But, then that may itself be a matter of semantics.

I started all this because Mike used the 36/35.5 ratio in his initial example.  I can only assume that he had a temporary brain freeze because this is clearly not how one calculates either percent shrinkage or percent stretch.  It's a ratio and not a percent change.  I only jumped into this because Seder then was led astray and used the ratio as Mike seemed to be suggesting.  He asked Mike if he was correct and Mike responded that he was when he clearly was wrong.

I then made my initial 10% instead of 1% mistake but that was just a slip on my part and not fundamental to my argument.

After wandering around a bit, I finally looked at the QU box to be filled in.  If you hover your mouse over the box it says "Stretch the length by this amount" and it asks for a percent.  Therefore, for the intended 36-inch print that shrank to 35.5 inches, I would say that what Mike seems to be wanting is to stretch a 35.5 inch result to 36 inches.  I think this would properly require a "stretch" computed by

100*((36 - 35.5)/35.5 = 1.408%

If, on the other hand, Mike really intends the input to be the amount of "shrinkage" from what is intended, then since we want 36 but are getting 35.5, the shrinkage number would be

100*((36 - 35.5)/36) = 1.389%

Obviously this "semantic difference" is probably of no practical concern unless of course Mike really means to use the ratio.

Jim H

Usually, when swimming, if the water temperature in the lake or ocean is cold, there will be shrinkage.... not sure how you calculate that!

Fred
 ??? :P :-\

You are sure your trunks did not expand instead?

http://www.powerhousemuseum.com/collection/database/?irn=91382


met vriendelijke groeten, Ernst
Shareware too:
330+ paper white spectral plots:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm

I wanted to keep it as simple as possible for users.  You guys are making it as complicated as possible.  Take the intended length and divide by the actual length that came out of the printer.  Use that as a percentage.  If you print 36 inches and you get 35.25 inches, it's 36/35.25 or 1.02... so use 2%.  As the tool tip says when you hover over it, it stretches by that amount to compensate.  So your 35.25 inch print (actual) is going to get stretched by 2%.  2% of 35.25 is .75 inch and that's the stretch you want.

Mike

Mike,

I'm going to make one more comment and then I'll slink away.

What got me started was your initial use of the 36/35.5 = 1.04 example instead of the usual calculation of stretch percentage that Ray and I seem to agree on.  This led Seder to ask if, when needing to stretch from 20 inches to 20.2 inches, he should put 1.01 into the input (20.2/20 = 1.01) .  You then said that using 1.01 is correct but it is clearly not.  This is partly what led me a little astray.

What I had not realized is that what you are saying is that you can use the ratio calculation if you use the fractional part of the result (multiplied by 100).

Example: Suppose you want to stretch from 40 inches to 50 inches.

50/40 = 1.25 ---> 0.25*100 = 25%

The more usual percentage calculation would be

100*((50 - 40)/40) = 25%

Voila, the same answer!!

A little algebra shows why this is so:

Let d = desired length

      r = resultant length

Then

      100*((d/r) - 1) = 100*((d - r)/r)

This little result had escaped me.

It's been fun!

Jim H. 

I think we gots it now!  Yeah, I should have mentioned that you don't put 1.01 in the input box but rather use that as a percentage (the fractional part*100).  In my mind, I was assuming that part because the box says %.  :)  I'll explain this as simply as possible in the next revision of the help.

For now, the tool tip says it most concisely: "stretch the length by this amount" which is correct.  What the program is actually doing is adding 2% to the length if you enter a "2" in the box.  And that fits with your math above.  That makes the math as simple as possible for users.  Take the specified print length (36 for example), divide by the actual print length that comes out (35.5 for example), and your answer is sitting on the display: just ignore the one and shift the decimal 2 places to the right.  36/35.5 = 1.014084507, so 1.01.4084507% (1.4%) is your answer.

Mike

Mike,

As the late, great Etta James sang "At Last"!  The answer has come along.

I'm glad we are on common ground now.  The only criticism I might offer after all this is that your method of using a ratio and then subtracting one and then shifting the decimal two places to the right, although simple, deviates from what people would normally do when asked to calculate a percentage stretch.  I may be wrong but my guess is that most would calculate it using the definition of percentage change (i.e. 100*change/base) instead of what might be regarded as somewhat of a mathematical trick.

And I said I was through ...

Jim H

Jim,

Mike used to, maybe still does, program in Pascal, iirc. That is one huge mathematical trick. I know many folk who used that language, it tended to distort their view of reality  ;) ;) ;)

By saying that, it tended to make them think of short cuts, different ways of doing things, which were not necessarily obvious to us lesser mortals stuck with Fortran, Cobol, and the like.

fwiw, Mike is saying the same as you, except he's not expressing it with the maths required to shift 1.02 to 2% - but we know that anyway. I wonder if the sharpening (which depends on print size) is adjusted accordingly  ;D

Best wishes,

Ray

Your way is just harder to do and harder to explain and is more prone to mistakes.  To get "change" in your method, you have to do a subtraction first which puts a third number into the mix, then divide that third number by the base (and half the time people will divide by the wrong number - the smaller one), then multiply all that by 100.

Personally, I think it's easier to just tell people to take the larger number and divide it by the smaller one and the answer is on the calculator!  Just look at the third digit, add a decimal point, then add the fourth, and fifth digits and you have your answer.

Both ways work, so take the easier one.  If doing a subtraction, plus a divide, plus a multiply is easier for you, I can't argue.  For most people, I'll tell you from experience, half the time they won't know whether the "base" is the 36 inches or the 35.5 inches.  Larger number divided by smaller number and start at digit 3 on the calculator is a lot easier for most.

Mike

See above.  :P  Coding in any language teaches you how to be efficient.  Being able to get the answer on your calculator with one divide using two numbers is a lot better than doing a subtraction, trying to remember the result, dividing that by the larger of the two numbers you started with (remembering not to accidentally use the smaller one), and then multiplying that whole deal by 100.  And for what?  Because you can't ignore the "1" on the calculator and use the 3rd, 4th, and 5th digit on the display?  Doing all that nonsense is what a C++ programmer would do.  :)

Mike

Precisely

Mike,

I think we can argue this all day and probably not agree on the best method.  Your approach certainly works but I am convinced that only a minority of people would use your method to calculate percent change whatever the situation.  In my opinion you should not tell users how to calculate the required percent stretch at all.  Better to just define precisely what the input requires and leave it to the user to use whatever method he prefers, either mine and RayW's or yours.

You are making an argument that your method is easier and simpler than mine.  I would argue that using your method is essentially using a mathematical trick that has the big disadvantage of basically ignoring the natural definition of percent change which is 100 times the fractional change where the fractional change is the change or delta from some base value divided by the base value.

In my experience it is better to remember a definition and do calculations based on that definition than to remember a trick that gives the same answer.  I argue, but you may disagree, that your method bears no obvious relation to the definition.

By the way, I do not subscribe to RayW's suggestion that your "view of reality" has been somehow distorted by Pascal programming.  I am a retired engineer who programmed in Pascal, basic, C, and Fortran (mostly Fortran) and I don't feel that my view has been distorted (although friends and family may disagree).  On the other hand, during many years of working with numbers, it never occurred to me to calculate percent change in the manner you suggest.

I think I can anticipate your rejoinder.  You are going to say that many Qimage users don't know enough about the definition of percent change to do the required calculation.  This is probably true of those who print on canvas.

Jim H.

Mike,

You said


I can't resist commenting on this.  The typical C and C++ programmer just revels in the tricky and sly shortcut.  He is always trying to compress the algorithm into the shortest and most incomprehensible code possible.  Therefore, he would favor your method.  The typical plodding Fortran programmer can't remember tricks and must start from first principles and therefore would favor my method.

Jim H.

Hi Jim,

Well, from the user's point of view, I would guess since QI knows the size he's aiming at (36 in examples above), then all he needs to enter is the size he actually gets (35.5), so no need for the user to calculate anything. It's up to the programmer to choose whatever method he likes in getting to the result he needs, bearing in mind documentation and maintenance issues, of course.

I bought Borland Pascal before Philippe Kahn moved to USA. It was for a cpm machine, iirc. It consisted of a couple of floppies (5 1/4 iirc, or maybe 8 inches) and a dozen or so duplicated sheets for the manual - not even printed, stencil duplicated. You can now version 1 and later versions for free. I don't remember actually using it, but many did. Interesting article on the Wiki, you can see how Borland was 'different', even from the origin of the original code. Having started out different, it is difficult to later conform to more widespread standards, without upsetting and maybe losing your existing customer base.

Best wishes,

Ray

(Next week, a dissertation on alternative uses for punched cards  :o )

RayW,

Mike is going to kick us off his forum if this goes too far, but ...

Very early on I programmed in basic on a CPM machine.  Then I discovered Phillippe Kahn's Turbo pascal.  I thought it was wonderful, especially compared with basic!  I did home programming in pascal on DOS and Windows up until the advent of object pascal.  I also did home programming on Borland C.

Kahn's products have always impressed me.  Interestingly, I am now using a GPS navigation app on my iPad called MotionX Drive GPS which is a Phillippe Kahn product.  It is very good and I now use my iPad as my primary GPS navigator, supplanting my Garmin.

Essentially all of my programming at work was in Fortran, primarily simulation of dynamic systems in the aerospace industry.

As for punched cards, when I started Fortran programming everything was on boxes of cards.  We got our output on a big stack of paper and then plotted results by hand on graph paper.  Those were the days!!

Cheers,

Jim H.

In my Photoshop actions for canvas wraps I advise adding a percentage on the print length, the user is given 100 for both directions in that menu, I expect they can make that 100,5 for one direction if only a 0.5 % is needed. Maybe I do expect a bit too much of user's math's skills.

On stretching canvas, there is a wide variety of qualities and how they are stretched on the frames. Not to mention the influence of the varnish applied. The pneumatic stretcher I made for my own shop certainly gives much more tension than possible with manual stretching. The percentage added for the shrink (from the roll tension) is often less than the differences that exist between stretching methods.


met vriendelijke groeten, Ernst
Shareware too:
330+ paper white spectral plots:
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm

In the next version, I'll probably just put a "rt click = calculate" in the tool tip.  Then when you right click, a box pops up that has two entries: one for the specified length and one for the actual printed length.  Then not only do you have an easy way to calculate, but it also shows you how it's done.

As for programming languages, Fortran is actually the only one I've never used.  I used assembly language to write games in the early 80's and switched to Turbo Pascal in the later 80's as it was the fastest compiler by far and not a whole lot slower than assembly language when actually compiled.  Then I switched to C and used that for a few years when Pascal fell off the radar.  After a few years of C with its curly brackets, == signs, and pointers-to-pointers-to-pointers where you could never seem to really just reference a variable, I realized I was a lot more efficient in Pascal.  C just hurt my head, trying to look at a screen full of nothing but symbols... looked a lot more like the matrix than code.  It was efficient in the written code --> machine code arena but highly inefficient in the design arena, with no well thought out IDE.  Then Delphi came along and I never looked back.  Not only could I design and program 10x faster than in C, I could develop faster than just about any C programmer.  Even better, the compiled code was just as efficient and in many cases, more efficient than what I was writing in C because the compiler was so refined that it optimized everything whereas in C, you had to be really careful and use a lot of tricks to get the same efficiency.

Now, with Delphi up to its 12th edition and supporting Unicode, 64 bit, cross-platform, it's here to stay.  It's definitely the most advanced tool available for RAD (rapid application development).  It's the reason that one developer can bring you Qimage.

Mike

Mike,

I think you have hit on the solution to the stretch problem.  That should remove any confusion over calculating percent stretch.

As for programming languages, I had similar feelings about C as you did.  Having always used Fortran at work, I never could wrap my brain around pointers and assorted features.  I did Pascal and C programming at home for hobby purposes.  I really did like Pascal (Turbo and Borland) but never got comfortable with C.

Fortran has a reputation as being out of date compared to more modern languages but for engineering computation, it is still powerful.  The newer versions are now even incorporating some of the structured and object-oriented programming features of the more modern languages.  However, when I retired six years ago, I was still using the old non-structured stuff for the most part, not finding the the new features really necessary.  Old dogs and new tricks, you know.

Jim H.   

Hi Jim.

going from linear to object oriented, I was lucky to be 'mentored' by a guy from IBM. The solution is easy, as he explained to me -'You unplug your brain, and then plug it in again, but sideways'. It's one of those things that takes a year of frustration, and then it suddenly clicks, and you can't then even think about doing it in the old way.

Best wishes,

Ray

True.  When you start doing object oriented work, the next step is to realize that even more important than the programming language of choice is to pick a good IDE.  A cumbersome and non-visual IDE, to me, is even worse than a cumbersome language.

Mike