Numeric derivation from iminfo

Hi there,

I'm trying to solve the following problem with the iminfo function using info structure for a jpg and png format

out_perf = pixel_rate_MHz * plane_source_bytes_per_pixel * memory_value_microseconds  

where

pixel_rate_MHz = Horizontal_Active_Resolution * Vertical_Active_Resolution * Refresh_Rate * (1+ Blanking_Period/100); % need help
plane_source_bytes_per_pixel = ?? % Need help
memory_value_microseconds =?? % Need help    

Could someone please help me in determining the parameters?

Thank you very much.

Answer 1

[Walter Roberson]

unfortunately in practice the large majority of the time, doing this computation is useless. A lot of images do not have the resolution stored, and it is extremely common to find that the stored resolution is 100 if the image was created using Windows software, or 72 if created using Apple: that is, nominal values are filled in that have nothing to do with the actual resolution.

Calculating actual resolution using the content of the images is not possible unless the image contains items of known size.

I notice however that the equations talk about clock rates and similar. Those kinds of calculations are used for calculation of bandwidth requirements or transmission time requirements, and in such situations, the resolution of the images is irrelevant, with the calculation needing to know the size of the image, rows and columns and color panes, and bits per pixel.

Remember, resolution of a pixel is the real world distance between adjacent pixels. If you were to put in a 10:1 magnifying lens then the resolution would get 10 times higher (until you get down to distances comparable to the wavelength of the light) but the sensor still has the same number of pixels and would record 1/10 as large of a space, leading to the same number of pixels. Resolution is not the number of pixels. An electron force microscope might only produce 16 x 16 pixels but the resolution might be in the nanometer range.

[Life is Wonderful]

Thanks @Walter Roberson,

Unfortunately, your assistance is not moving me forward.

I sharing an example to demonstration purpose

4 bytes per pixel plane source, pixel rate 108 MHz, and memory value of 7.5:

intermediate value = 108 MHz * 4 Bpp * 7.5 = 3240

final value = ceiling[(3240 / 64) + 2] = 53

I don't have any other options, so if you could help me with some approximate calculations, that would be fantastic.

Thank you very much.

[Steven Lord]

Can you explain in words not code exactly what you're trying to compute about your image files?

If as I suspect from Walter's description you're trying to find the real-world size of an object in an image, I agree that unless you have some object of known size in the image it's going to be difficult or impossible to compute the size.

Consider two pictures, one of the Eiffel Tower and one of a well constructed Eiffel Tower souvenir from the gift shop. Could you take a picture of the two in the same orientation so they look the same? Yes, probably. How would you distinguish between the two?

Or consider a well made model railroad layout. Aside from the size, I've seen some that look incredibly life-like. How would you distinguish between a picture of such a layout and a picture of a real town just from the image?

[Walter Roberson]

Horizontal_Active_Resolution is vaguely related to info.Width

Vertical_Active_Resolution is vaguely related to info.Height

Refresh_Rate and Blanking_Period are irrelevant for jpeg and png and all other static images. They are relevant only for video formats.

plane_source_bytes_per_pixel is vaguely related to info.BitDepth

memory_value_microseconds is not a name that I recognize. It is certainly not used for static images such jpeg and png. It sounds like it might refer to some kind of latency in transmission, but the calculations are set up wrong for that possibility.

Perhaps memory_value_microseconds is related to how long it takes to retrieve a byte from memory, and perhaps the calculation has to do with the required time to transmit a video. Except frame blanking is only relevant if you have more than one frame but number of frames is not factored into the equation. Furthermore, memory is not being used during the frame Blanking_Period so it is a mistake to multiply the Blanking_Period by memory costs. And if it does have to do with memory access then the equations fail to take into account DMA and fail to take into account cache lines or predictive fetching; in a well designed program on a modern processor, copying out a block of contiguous memory encounters memory delays for the first cache line but after that bytes are already available when needed because of predictive fetching.

[Life is Wonderful]

Thanks @Walter Roberson!!

Almost there to the expectation / I think you 've a very good understanding for my calculation

Refresh_Rate and Blanking_Period are irrelevant for jpeg and png and all other static images

Good point, so which images contains the Refresh_Rate , and Blanking_Period when analyzing a video , I am converting the video to frames and frames i am reading, and then I am making the calculation using frame properties aka iminfo ?

plane_source_bytes_per_pixel is vaguely related to info.BitDepth

This is usually 8 or 24 bits retrived from gray and color pixel property

Except frame blanking is only relevant if you have more than one frame but number of frames is not factored into the equation

Blanking_Period : This is hit ratio , say 1:15. But i am not sure when someone is analyzing a video

I am clear now you have a good understing about the problem and What I am trying to make the analysis

Thank you !!

[Walter Roberson]

You still need to tell us in words what you are trying to do. I can think of a couple of different possibilities, but you are using the wrong equations for all of the possibilities that I can think of.

[Life is Wonderful]

Hi @Walter Roberson

There are memory controller configuration needs that are not listed , and I am currently attempting to programme display configuration registers that must be programmed in order to run for display to operate in a differemt power mode alsonside various bandwidth settings.

In order to configure the display engine, I am performing an offline analysis in which I transform the video into frames and read each frame. I hope you have the background understanding clear.

Thank you

[Life is Wonderful]

pixel rate equation, For your reference I 've added an equation.

Please help me . Thank you

[Walter Roberson]

In order to configure the display engine, I am performing an offline analysis in which I transform the video into frames and read each frame.

Do not do that. You can extract the height and width and nominal frame rate and color depth from the video using mmfileinfo . That information will not be different for different frames, so there is no point extracting the frames. The frame rate is not something that you can determine from the individual frames, so extracting the frames will not permit you to establish the frame rate.

[Life is Wonderful]

Thank you!!

OK, what about Blanking_Period param ?

[Walter Roberson]

according to the article, blank period percent is a characteristic the hardware and is to be looked up in the documentation of the hardware.

You might find it instructive to look at the description of NTSC, with its horizontal retrace and vertical retrace and "front porch" and "back porch". Modern digital hardware does not need all of those but it might need some of them depending on the technology.

[Life is Wonderful]

Sure.

Thanks a lot .