pixel dimensions linked to resolution???

[Gregory C]

I'm having big problems with HDR (v6.2.1r3).

when I open images, HDR calculates the pixel dimensions based on the resolution of the image!!! it's incredibly confusing. maybe I'm just an idiot but I thought that pixel dimensions are constant regardless of resolution; ie, a 1000 x 750 pixel image is always 1000 x 750 pixels if it's 72 dpi or 300 dpi. I can understand that the original dimensions might change for fixed length units such as points (ie, 1/72 inch), cm and inches but not pixels.

examples of the problems I'm having.

my Canon camera saves the jpeg images as 2272 x 1402 pixel 180 dpi images. when HDR opens these, the original dimensions are shown as 2272 x 1402 at 180 dpi. if I move the resolution slider, the original dimensions change accordingly. for example, moving the slider to 200 dpi, the *original* dimensions change to 2524 x 1893 (200 / 180 * 2272).

if I add several images to the Job Manager queue, *all* of them 2272 x 1402 pixels but some at 72 dpi, some at 180 dpi and some at 300 dpi, the dimensions of the images in the job queue all differ.

extreme confusion!!! trying to export the images at a concise xDim x yDim at 72 dpi is proving to be very difficult.

am I wrong? are original pixel dimensions supposed to change as the resolution changes? enlighten me please.

I have reported this to support (sent to Jan) but have not yet received a reply. (and of course, this happens just when I'm in a spot and need to export photos for professional use)

regards
Gregory

[LSI_Magnussen]

Dear Gregory,

I suppose that you have the pixel lock closed (it's the one next to the file size static text). When this lock is closed (it's closed per default), no scaling will take place; when you change the resolution, output pixel dimensions will stay fixed, only the output dimension in e.g. inch or cm will change accordingly.

Further explanation using your example values:
Your image has a size of 2272 x 1402 pixel at 180 dpi, that means the original size is 12.6 x 7.8 inch (please change the dimension in SilverFast to inch and not pixel for the moment).
If you change the resolution to e.g. 72 dpi, SilverFast will still display an original size of 12.6 x 7.8, but an output dimension of 31.6 x 19.5 (180/72 * 12.6), the scaling changes from 100% to 250%. Given the fixed pixel dimensions, the output dimension in inch changes with the resolution.
So now to your problem: When you choose pixel values to be displayed in SilverFast, the following happens: As the output values are fixed (2272 x 1402) and the scaling still changes when changing the resolution, the original values change too to reflect the correct calculation of orginial x scaling = output. I agree that this is irritating, but I think it should be understandable if you consider the situation where SilverFast does display inch or cm values.

Regarding the JobManager:
It always displays the output dimension, so if you have some entries in the JM from the same image, but with different resolutions and you choose pixel as displayed dimension, every entry in the JM will show 2272 x 1402.

Regards
Ralf

[Gregory C]

two things.

(a) none of the three Locks are on. yet, the original pixel dimensions change as I change the output resolution.

(b) when I add my images to the job queue; some of them with a resolution of 72, some with a resolution of 180; they *do* show different pixel dimensions in the queue. I sent a screen shot to Jan. he hasn't replied to my email message so I cannot be sure that he received my message. I can send more examples to other tech people at Lasersoft if required.

does resolution change the size of the pixels or just the spacing? (remembering that pixels are not printer "dots") I really feel that pixel count should be unaffected by resolution. I should be able to change the resolution of an image without affecting its pixel count. pixel count should only be affected by the scale factor.


here's a reproducable example (SF HDR 6.2.1r4):

in your Options, make sure that your default units are Pixel.

in the Frame panel, all padlocks are OFF (they are off by default).

2 images:
A 2272 x 1402 pixels, 72 dpi
B 2272 x 1402 pixels, 180 dpi

open A in SF while SF is in pixel mode.
SF shows A as being 2272 x 1402 at 72 dpi.
slide the resolution to 200 dpi.
SF shows A's *original* size as being 6311 x 4733 pixels.

open B in SF.
SF shows B as being 2272 x 1402 at 180 dpi.
slide the resolution to 200 dpi.
SF shows A's *original* size as being 2524 x 1893 pixels.

(to further confuse you, SF remembers the output resolution you set for each image. if you later reload the image, SF will show the resolution that you previously set for it rather than its original resolution! try reloading image A. SF will not show 72 dpi. it will show 200 dpi.)

now set the scale to 50% and the resolution to 72 dpi.
*bummer*. it's not that easy. if you specify 50% and then 72 dpi, SF changes the scale to something different. you have to go back and specify the scale to 50% again. this is not good!

save the Setting as Pixel Test.
(Settings remember the scale, not the output dimensions)

open the VLT and navigate to the two images.
open the Job Manager window.

drag the 72 dpi image to the Job Manager queue.
when the dialog appears, specify the Pixel Test setting, uncheck "Keep original resolution" and uncheck "Adjust images automatically".
the image appears in the queue as 1136 x 852 pixels at 72 dpi which would seem correct.

repeat the process with the 180 dpi image.
the image appears in the queue as 454 x 341 pixels at 72 dpi ?????

confused yet? I am.

what's going on?

regards
Gregory

[LSI_Magnussen]

Dear Gregory,

OK I see the problem. I probably have to admit that you face a display (maybe usage) bug in SilverFast.
The whole thing regarding original size, scale and output size was built with real dimensions (cm or inch) in mind. If you use SilverFast with the dimension set to e.g. inch, everything works OK. Changing the output resolution just changes the resulting image file size when the pixel lock is opened; original size, scale and therefore output size will stay the same.

When you use pixel dimensions, the problem is, that scale still shows the real value (ouput dimension / original dimension in inch), e.g. 100%, so when you change the resolution, the output dimension in pixel changes, scale is still 100%, so the display value for the original dimension changes too to still fulfill the calculation original * scale = output. It's just a display bug; SilverFast should show a different scale value in that case, not a different original value.

(to further confuse you, SF remembers the output resolution you set for each image. if you later reload the image, SF will show the resolution that you previously set for it rather than its original resolution! try reloading image A. SF will not show 72 dpi. it will show 200 dpi.)

It's the normal behaviour of SilverFast to remember the user settings including the resolution. Why should SilverFast remember everything, but not the resolution? Makes no sense for me.

repeat the process with the 180 dpi image.
the image appears in the queue as 454 x 341 pixels at 72 dpi ?????

Well, the image is scaled by 50% and the resolution is reduced by factor 180/72 = 2.5
=> 2272 * 0.5 * 1/2.5 = 454

Still confused?

Ralf

[Gregory C]

thank you for answering Ralf.

still confused?

not confused anymore but it means that SF is great for images headed for paper, but not so convenient for images headed for the internet where pixels mean everything and resolution has no real meaning; ie, jpegs always display at 1 image pixel per monitor pixel and designers specify web sites by pixel count and not inches or resolution (for the moment anyway).

it would be great if SF had the option (in Options) to either be length-centric (the way it is now where the size/diameter of every pixel is calculated according to the dpi value) or pixel-centric where resolution has no affect on the number of pixels in either the original or the output dimensions (a pixel is a a pixel).

SF needs to make working with images in pixel terms more straight forward. again, my suggestion for the 'pixel mode' would be:

(a) the original dimension in pixels of the image never changes
(b) the output dimension in pixels is only affected by the Scale factor
(c) the resolution only affects the resolution of the pixels without affecting the pixel count or the pixel 'size/diameter'.

this would make working with images for the internet or for on-screen viewing so much easier but would of course require a distinct mode because these rules could obviously not apply while working with real dimensions (inch/cm).

It's the normal behaviour of SilverFast to remember the user settings including the resolution. Why should SilverFast remember everything, but not the resolution? Makes no sense for me.

the confusion comes about because the resolution slider was a method of identifying the original resolution. if SF remembers the output resolution for each image whenever it's reloaded, there's no way for the user to know with any certainty the original resolution of the image without opening it in another application like GraphicConverter or Preview.

SF should perhaps add an Original Resolution field just below the Original dimensions so that the user can instantly see both the original and output resolutions.


regards
Gregory

[LSI_Magnussen]

Dear Gregory,

I already added an entry to our internal bug/feature request database regarding the handling when pixel dimensions are used, so sooner or later we will hopefully change/fix this.
Thank you for your suggestions.

Regards
Ralf