The TIFF created when triggering an Edit in... command in LR is usually stacked with the original image, not deleted.

Good idea. Thanks.

Hi Fred,


Not convinced . QU knows the aspect ratio of the full image. So it can quickly computes whether the short side of the full image will be longer than the acceptable value. I don't see what information could be mising in order to make this computation. Actually it does make this computation just after I clicked Yes since it doesn't add a new page to the job. So it has all the needed information to make a decision immediately without asking me for something it already knows.

Anyway, clicking on Yes is not a very time consuming task. It's just one of the small details that make the QU user interface so strange and sometimes so disturbing. I just switched to QU but I have been using QI since years. I like the print quality produced by this software but I never got used to its user interface.

Thanks very much. I'll give this approach a try.

Exactly . This should be possible since QU is already able to update the size related fields on-the-fly.

Hi,

I can just confirm what DdeGannes said. Just create a new entry in the External Editing tab and point to qimage.exe. Set your export parameters and voilà, just use the Edit in... command and your file will be directly loaded into QImage. You'll not be able to load a RAW file this way, though. For me it's not a problem since I'm doing all editing in LR and/or PS + some plugins. Usually, if I don't print from LR, it's a TIFF file that I send to QImage anyway.

Hi,

I just noticed that QU accepts a filename on the command line. This makes possible to configure a new "Edit in... QImage" command in Lightroom. This way, you can directly load the image into QImage from Lightroom when you want to print it from there instead of using the Lightroom Print module.

The image is directly loaded into the default page/job. Very nice. The only thing that could enhance the process would be to automatically synchronize the tree and folder views in the left panes with the folder and file of the loaded image in case of direct loading from the command line.

Lightroom users may wonder why they would want to print from QU instead of Lightroom. Lightroom prints are usually not bad but in some cases, only QU can solve some severe problems. I recently had a B&W image containing a very strong luminance moiré and neither PS nor Lightroom could get rid of it when printing. Only QImage could print the image without any moiré.

I don't understand why the warning is issued. The page size is known, the printable area is known, the requested size is known, so it's easy to see that there will be no problem with the value used in my example. Why force me to go through this useless step?


It's actually a Yes / No choice. Yes gives the expected result. No results in resizing to the maximum possible size in the page.

Fred,

Thanks for the details and for your time.

However, this is not what I'd like to have.

1. The margin fields are not updated while I'm dragging with the mouse. I'd like to release the mouse button when I see that I have reached the desired value for the top or left margin (assuming the image will remain centered). The value indicated in the ruler for the margin is wrong because it will be changed once I have released the mouse button.

2. Assuming I want the top (and bottom) margin to be say, 20 mm, if I enter say, 20 mm in the top margin field the image will no longer be centered (although the Placement field in the Document area still - wrongly - indicates "Center"). Same for the bottom margin field. If I click on Center, the values I entered for the top or bottom margin are disregarded. I think this is not consistent. Since I specified that I wanted a centered image, if I enter a value for the top margin, it is assumed that the bottom margin should be the same. So the image should be zoomed in or out accordingly, keeping the image centered.

The behavior of the Print module in Lightroom is much more consistent regarding this point.

Hi,

I think there's a problem with the way drag and drop resizing is working. It should work according to the value of the Center print placement option. For example, for a single image, if I have selected Center, the dotted image frame showing the effect of resizing when dragging and dropping should extend in both directions from the center. The dotted frame should always remain centered if the image is centered. This would allow me to see, when the rulers are visible, what will be the actual value of the margins after resizing. For the kind of job I'm doing, I'm more margin-oriented rather than being image size-oriented.

The way the drag and drop resizing currently works forces me to calculate what the image size should according to the margins I want.

Thanks.

Hi,

I have a problem with the Custom size setting.

1. If I select "Enter specific size" and enter 277 x 190 mm for an A4 page, the actual sizing is correct.

BUT

2. If I select "Specify one dimension" and enter 277 mm for the LONG side (Landscape mode - Auto cropping is OFF), I get an error message saying that "Selected print size is larger than one page..." Which is obviously not true because this size was accepted in test #1.

Thanks.

Hi,

Does this mean that there's no discount when upgrading to Ultimate from an "older" Studio?

Thanks.

Hi Ray,

Yes, you are. I always delete the previous installation file just before installing a new version.

--
Patrick

Which obviously closes the discussion. But a developer or a software designer should never say never .


As a (seasoned) developer I always thought that the user's (customer's) point of view is the most important .

Anyway, I for sure do know that each user has his own way of understanding and dealing with the UI of any software. And a perfect UI doesn't exist. But a good UI is flexible and able to more or less adapt to the way a user works. A not so good UI forces the user to work the way the programmer decided (for good or bad reasons). If we consider the image selection issue, I can understand that other users are expecting another behavior than I am expecting. Since there is a choice between 2 or 3 possible behaviors, why not make this an option?

There's one thing I have learned during my (seasoned) developer's life. You may have produced a software with the best features of its category, be sure that there's no competition, etc. , the first impression the new user will have when trying QIMage has a direct impact on the sales. And believe it or not, the QIMage UI and the manual are not helping DDI Software sell this program. That's a fact and that's a customer's point of view, not a developer's point of view. But DDI Software might not want to sell more licenses?

The QImage help (which is also a part of the UI) is one of the most terrible manuals I have ever seen. Just ask a professional technical writer about this. It just breaks every single rule about writing a software manual (although I'm sure all the necessary information is available in that manual). Similarly, QImage is certainly able to do everything I want when it comes to print a photograph. The problem is how it gives me access to its rich set of outstanding features.

I certainly do not regret the money I spent for QImage and I always recommend this software and I will continue to do so. I'm just wondering why these remarks (from Ray and me) have caused so sensitive reactions.

--
Patrick

Yes it is. No discussion about that. Not its UI however. I'll try to find time to accurately describe what should be done or what's wrong. Just, I'm currently retiring and closing my shop. This will keep me busy for some weeks.

--
Patrick