Shrinking a 1024x768 to 320x240 ?

Go To Last Post
99 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I made :

 char temp_buffer[100],line[512];
	int count,z,bmpData,bmpAddr;
	int x = 0;
	int i,y = 0;
	int xx, yy,ny,nx;
    uint8_t hdr[0x28];
	UINT bytesread;
    uint8_t hdr_256[0x36];
    static uint16_t w[256];
    uint32_t off,sourcewidth,sourceheight;

			    //262K picture
			uint16_t destx;
			uint16_t desty;
			
			delay_ms(1500);
			 LCD_Clear(Black);            
			res = f_open(&fsrc, filename, FA_READ);
			
			f_read(&fsrc, hdr_256, sizeof(hdr_256),&bytesread); // Read header
			off = *((uint32_t *)&hdr_256[0x0A]); // offset to rasters
			            
			sourcewidth = *((uint32_t *)&hdr_256[0x12]); // X pixels
			sourceheight = *((uint32_t *)&hdr_256[0x16]); // Y pixels
			               
			               
			f_lseek(&fsrc, off); // Seek to the data
			destx = 0;
			desty = 0;
//for(y = 0, ny = 0; y < sourceheight; ny += 3, ny++)
for(y = 0, ny = 0; y < sourceheight; y += 3, ny++)
			               
			   {
			   if (ny == 5)
			      {
			      y++;
			      ny = 0;
			      }
			    
			    for(x = 0,nx = 0; x < sourcewidth; x += 3,nx++)
			      {
			      uint32_t rgb;
			      if (nx == 5)
			         {
			         x++;
			         nx = 0;
			         }
			      f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R
			      // RRRRRRRRGGGGGGGGBBBBBBBB 8:8:8
			      //         RRRRRGGGGGGBBBBB 5:6:5
			      rgb = ((rgb & 0xF80000) >> 8) | ((rgb & 0x00FC00) >> 5) | ((rgb & 0x0000F8) >> 3);
			      LCD_SetPoint(desty, destx, rgb);
				  
				
			      
				  destx++;
			      if(destx == 320)
			         {
			         destx = 0;
			         desty++;
			         }
			      }
			   }
				f_close(&fsrc);
				delay_ms(2000);

I got :

Please let me know what I miss here ?
thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although you are counting to every third pixel, you are just reading consecutive pixels from the large image. You need to either read and discard all the intermediate pixels, or fseek to the one you want. I have no idea as to which would be quicker, but with the code as it is, it would probably be easier to use the x and y values to calculate a new offset in the file to fseek to.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So every time you read the rgb values from the file you need to to calulate the offset within the file.
Have a new variable, pixeloffs, and do something like

pixeloff = offs + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel
f_lseek(&fsrc, off); // Seek to the desired pixel
f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R 


 

Note that this works because the big image width is 1024. If it was some other width, you would need to work out the row size, as I believe rows are padded to be multiples of 4(?) bytes.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmm.....try to understand...I'll get back later..thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
So every time you read the rgb values from the file you need to to calulate the offset within the file.
Have a new variable, pixeloffs, and do something like

pixeloff = offs + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel
f_lseek(&fsrc, pixeloff); // Seek to the desired pixel
f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R 


 

Note that this works because the big image width is 1024. If it was some other width, you would need to work out the row size, as I believe rows are padded to be multiples of 4(?) bytes.

Edit: Corrected line above, the seek is to pixeloff, not offs.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
John_A_Brown wrote:
So every time you read the rgb values from the file you need to to calulate the offset within the file.
Have a new variable, pixeloffs, and do something like

pixeloff = offs + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel
f_lseek(&fsrc, pixeloff); // Seek to the desired pixel
f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R 


 

then display those pixels into the LCD with LCD_Setpoint ? thanks
Note that this works because the big image width is 1024. If it was some other width, you would need to work out the row size, as I believe rows are padded to be multiples of 4(?) bytes.

Edit: Corrected line above, the seek is to pixeloff, not offs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hate to ask this lo level question, but we have to assume the drawing stuff works well and you can draw a box around the lcd and two vertical lines on the left and they actually show up as vertical lines on the left, not right, not horizontal, not diagonal? OK, good. Now we can use the lcd to look at the picture. How about cooking up a 320x240 bmp and test reading that? Looks ok? Great. I'd try 640x480 next.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a chance to work a bit more on my Windows program to try various types of scaling but stopped after the first attempt because to these tired old eyes it actually looks pretty bloomin good without bothering to explore other options. This is the scaling I used:

    if (dispBmp) {
	    MemDCFILE = CreateCompatibleDC(hDC);
	    SelectObject(MemDCFILE, dispBmp );
		if (scaled != TRUE) {
		    GetObject( dispBmp, sizeof(BITMAP), &bm );
		    BitBlt( hDC, 10, 10, bm.bmWidth, bm.bmHeight, MemDCFILE, 0, 0, SRCCOPY );
		}
		else {
            HBITMAP hNewBmp;
			HDC hEditDC;
			int x,y;
            hNewBmp = CreateCompatibleBitmap(GetDC(hwnd), 320, 240);
			hEditDC = CreateCompatibleDC(GetDC(hwnd));
			SelectObject(hEditDC, hNewBmp);
			for (y=0; y<240; y++) {
				for (x=0; x<320; x++) {
					SetPixel(hEditDC, x, y, GetPixel(MemDCFILE, x * 3.2, y * 3.2));
				}
			}
		    BitBlt( hDC, 10, 10, 320, 240, hEditDC, 0, 0, SRCCOPY );
            DeleteObject(hNewBmp);
			DeleteDC(hEditDC);
        }
        DeleteDC(MemDCFILE);
    }

    EndPaint(hwnd, &ps);

As you can see all I do is step x,y for the dimensions of the destination image and set the output pixel (SetPixel()) to the pixel at GetPixel(x*3.2, y*3.2) from the source image.

As I say the result looks pretty darned good to me... though I suppose some of Amelia's more vertical whiskers have disappeared a bit?

For completeness I may try the 3,3,3,3,4... thing and also 3x3 or 4x4 averaged grids but, to be honest I don't see a lot of point.

Of course this "costs" a "* 3.2" operation but that doesn't matter on this multi-GHz PC ;-)

If anyone's interested I can upload the complete Pelles C project that created this Windows application.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is suprisingly good.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So when a user mode app in windows calls the setpixel() sub in the linked in runtime lib, it calls a sub pointed to in the graphics driver, could be directx (whatever that is), GDI, the driver in the firmware of the graphics card. It could be doing some sort of antialiasing/smoothing/texturing. Who knows whats going on. Who even knows how many layers of api there are?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To Clawson, I wish I can do

GetPixel(MemDCFILE, x * 3.2, y * 3.2)

on my code...
I wish...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I hate to ask this lo level question, but we have to assume the drawing stuff works well and you can draw a box around the lcd and two vertical lines on the left and they actually show up as vertical lines on the left, not right, not horizontal, not diagonal? OK, good. Now we can use the lcd to look at the picture. How about cooking up a 320x240 bmp and test reading that? Looks ok? Great. I'd try 640x480 next.

no problem with 320x240, if I create first on PC and then copy to SD card,
have a look..
https://www.youtube.com/watch?v=P_Bvq7yXxIk

thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To John,

off = *((uint32_t *)&hdr_256[0x0A]); // offset to rasters
						 
xx = *((uint32_t *)&hdr_256[0x12]); // X pixels
  
yy = *((uint32_t *)&hdr_256[0x16]); // Y pixels
						  
						  
						  pixeloff = off + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel

it's "off" not "offs", isn't it ?
thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Yes.

I have tried it, still the same, no luck :( ....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post your actual code.

Quote:

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Post your actual code.
Quote:


Hi John,

Here's the code I used, please have a look and correct me if there's mistake, thanks

	int x = 0;
	int i,y = 0;
	int xx, yy,ny,nx;
    uint8_t hdr[0x28];
	UINT bytesread;
    uint8_t hdr_256[0x36];
    static uint16_t w[256];
    uint32_t off,sourcewidth,sourceheight,pixeloff;

			    //262K picture
			uint16_t destx;
			uint16_t desty;
			
              delay_ms(1500);			             LCD_Clear(Black);            
	res = f_open(&fsrc, filename, FA_READ);
					f_read(&fsrc, hdr_256, sizeof(hdr_256),&bytesread); // Read header
off = *((uint32_t *)&hdr_256[0x0A]); // offset to rasters
			            
sourcewidth = *((uint32_t *)&hdr_256[0x12]); // X pixels
sourceheight = *((uint32_t *)&hdr_256[0x16]); // Y pixels
			               
pixeloff = off + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel
f_lseek(&fsrc, pixeloff); // Seek to the desired pixel			               
//f_lseek(&fsrc, off); // Seek to the data

destx = 0;
desty = 0;
//for(y = 0, ny = 0; y < sourceheight; ny += 3, ny++)
for(y = 0, ny = 0; y < sourceheight; y += 3, ny++)
			               
			   {
			   if (ny == 5)
			      {
			      y++;
			      ny = 0;
			      }
			    
   for(x = 0,nx = 0; x < sourcewidth; x += 3,nx++)
			      {
			      uint32_t rgb;
			      if (nx == 5)
			         {
			         x++;
			         nx = 0;
			         }
f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R
   // RRRRRRRRGGGGGGGGBBBBBBBB 8:8:8
   //         RRRRRGGGGGGBBBBB 5:6:5
rgb = ((rgb & 0xF80000) >> 8) | ((rgb & 0x00FC00) >> 5) | ((rgb & 0x0000F8) >> 3);
     LCD_SetPoint(desty, destx, rgb);
				  //sprintf(temp_buffer,"%.2d",rgb);printf(temp_buffer);printf("\n");
				
			      
				  destx++;
			      if(destx == 320)
			         {
			         destx = 0;
			         desty++;
			         }
			      }
			   }
				f_close(&fsrc);
				delay_ms(2000);

trying to fix identation, it's ok on my compiler... but change if I copy here....different size

Last Edited: Mon. Apr 28, 2014 - 08:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 int x = 0;
   int i,y = 0;
   int xx, yy,ny,nx;
    uint8_t hdr[0x28];
   UINT bytesread;
    uint8_t hdr_256[0x36];
    static uint16_t w[256];
    uint32_t off,sourcewidth,sourceheight,pixeloff;

             //262K picture
         uint16_t destx;
         uint16_t desty;
         
         delay_ms(1500);
          LCD_Clear(Black);           
         res = f_open(&fsrc, filename, FA_READ);
         
         f_read(&fsrc, hdr_256, sizeof(hdr_256),&bytesread); // Read header
         off = *((uint32_t *)&hdr_256[0x0A]); // offset to rasters
                    
         sourcewidth = *((uint32_t *)&hdr_256[0x12]); // X pixels
         sourceheight = *((uint32_t *)&hdr_256[0x16]); // Y pixels
                        
         f_lseek(&fsrc, off); // Seek to the start of the pixel data

         destx = 0;
         desty = 0;

         for(y = 0, ny = 0; y < sourceheight; y += 3, ny++)
                        
            {
            if (ny == 5)
               {
               y++;
               ny = 0;
               }
            
             for(x = 0,nx = 0; x < sourcewidth; x += 3,nx++)
               {
               uint32_t rgb;
               if (nx == 5)
                  {
                  x++;
                  nx = 0;
                  }
       pixeloff = off + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel
         f_lseek(&fsrc, pixeloff); // Seek to the desired pixel                        

               f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R
               // RRRRRRRRGGGGGGGGBBBBBBBB 8:8:8
               //         RRRRRGGGGGGBBBBB 5:6:5
               rgb = ((rgb & 0xF80000) >> 8) | ((rgb & 0x00FC00) >> 5) | ((rgb & 0x0000F8) >> 3);
               LCD_SetPoint(desty, destx, rgb);
              //sprintf(temp_buffer,"%.2d",rgb);printf(temp_buffer);printf("\n");
              
              destx++;
               if(destx == 320)
                  {
                  destx = 0;
                  desty++;
                  }
               }
            }
            f_close(&fsrc);
            delay_ms(2000); 

But one more question. What display are you using? Does it have the abilty to auto-increment to the next pixel? All the 320 by 240 displays I've used have this function.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dangit, John.. Bianchi got the indentation (almost) right for once, and immediately you ruin it.. :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's because I copied and pasted his code into a text editor to modify it. The weird mixture of tabs and spaces creates massive chaos. I have a proper job to do and I can't be arsed to straighten it up.
If you look at the code I posted on the 26th at 12:56 you'll see that I did attempt to get the formatting right(for my preferred scheme) but it was back to usual with the next post from the OP, and complete with variable names like xx and yy.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But one more question. What display are you using? Does it have the abilty to auto-increment to the next pixel? All the 320 by 240 displays I've used have this function.

I don't know if it does,
It's SSD1289 320x240 262K colours

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A quick look at the datasheet reveals that it does.

Attachment(s): 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To John,

There's a progress

I followed the code :

	int x = 0;
	int i,y = 0;
	int ny,nx;
    uint8_t hdr[0x28];
	UINT bytesread;
    uint8_t hdr_256[0x36];
    static uint16_t w[256];
    uint32_t off,sourcewidth,sourceheight,pixeloff;

			    //262K picture
			uint16_t destx;
			uint16_t desty;
			
			delay_ms(1500);
			 LCD_Clear(Black);            
	res = f_open(&fsrc, filename, FA_READ);
			
f_read(&fsrc, hdr_256, sizeof(hdr_256),&bytesread); // Read header
off = *((uint32_t *)&hdr_256[0x0A]); // offset to rasters
      
sourcewidth = *((uint32_t *)&hdr_256[0x12]); // X pixels
sourceheight = *((uint32_t *)&hdr_256[0x16]); // Y pixels
			               
           

			destx = 0;
			desty = 0;
//for(y = 0, ny = 0; y < sourceheight; ny += 3, ny++)
for(y = 0, ny = 0; y < sourceheight; y += 3, ny++)
			               
			   {
			   if (ny == 5)
			      {
			      y++;
			      ny = 0;
			      }
			    
	    for(x = 0,nx = 0; x < sourcewidth; x += 3,nx++)
			      {
			      uint32_t rgb;
			      if (nx == 5)
			         {
			         x++;
			         nx = 0;
			         }
 pixeloff = off + (y * 1024 * 3) + (x * 3); // Assuming three bytes per pixel
 f_lseek(&fsrc, pixeloff); // Seek to the desired pixel			               
 //f_lseek(&fsrc, off); // Seek to the data
   f_read(&fsrc, &rgb, 3, &bytesread); // Read pixel B G R
  // RRRRRRRRGGGGGGGGBBBBBBBB 8:8:8
     //         RRRRRGGGGGGBBBBB 5:6:5
 rgb = ((rgb & 0xF80000) >> 8) | ((rgb & 0x00FC00) >> 5) | ((rgb & 0x0000F8) >> 3);
 LCD_SetPoint(desty, destx, rgb);
				  				
			      
				  destx++;
			      if(destx == 320)
			         {
			         destx = 0;
			         desty++;
			         }
			      }
			   }
				f_close(&fsrc);
				delay_ms(2000);

Please let me know what do I miss here ? thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried another one :

on LCD :

It's diagonal, why is it ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
LCD_SetPoint(desty, destx, rgb);

Is this correct? It is, I think, more usual for x to be first:
i.e.

LCD_SetPoint(destx, desty, rgb); 

However, it looks to me as though something is out by a factor of two.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So when a user mode app in windows calls the setpixel() sub in the linked in runtime lib, it calls a sub pointed to in the graphics driver, could be directx (whatever that is), GDI, the driver in the firmware of the graphics card. It could be doing some sort of antialiasing/smoothing/texturing. Who knows whats going on. Who even knows how many layers of api there are?

Bob the functions I use are GDI from the WIN32 API. It is possibly one of the best documented programming APIs on planet earth:

http://msdn.microsoft.com/en-us/...

There is nothing "hidden" in the driver or what it does. If Microsoft says it sets a pixel to COLOREF on a bitmap selected into a device context then it sets a pixel in a device context - nothing more.

Quote:

To Clawson, I wish I can do

I fear you aren't getting the point of my posts and my small example program. There is nothing on earth stopping you doing the exact equivalent of:

GetPixel(MemDCFILE, x * 3.2, y * 3.2) 

In fact, you probably don't even need to pass a pointer to a device context/memory buffer as you aren't going to be working on lots of them. As for implementing GetPixel(x,y). Yes I know you only have a 512 byte sector buffer for the file read and yes, it may take some time to work out where in a file pixel (x,y) is then fseek() to that place and fread() the data (if you are lucky it's in the same sector you just read and will be buffered anyway - especially if you work across the X) but I would not try to do everything in huge cascades of nested for(x)/for(y) loops. Instead I would implement a GetPixel() and simply make sure that when you GetPixel(123,456) it really does return the colour of the pixel at that location. Similarly I would implement SetPixel() and then the conversion really does become as simple as:

         for (y=0; y<240; y++) {
            for (x=0; x<320; x++) {
               SetPixel(hEditDC, x, y, GetPixel(MemDCFILE, x * 3.2, y * 3.2));
            }
         }

Now I'll agree that this is not efficient code but it lets you work on the high-level design of the function. You can try other techniques for gathering the source pixels (and possibly averaging) and see how the results look. When you have found the "best looking" solution you now begin to look at optimisations for it that work best in a 512 byte sector buffer in the limited RAM of an AVR.

But do the high level design work first. Oh and did I mention that it would be 10 times easier to work on this in a PC program than on the limited resource hardware of an AVR?

BTW when you think about what my code is doing:

            for (x=0; x<320; x++) {
               SetPixel(hEditDC, x, y, GetPixel(MemDCFILE, x * 3.2, y * 3.2));
            }

it will be:

x      0    1    2    3    4    5    6    7    8    9    10
x*3.2  0    3.2  6.4  9.6  12.8 16  19.2  22.4 25.6 28.8 32
int(N) 0    3    6    9    12   16  19    22   25   28   32
+N     0    +3   +3   +3   +3   +4  +3    +3   +3   +3   +4 ...

So (I guess I'm a bit slow!) this IS just implementing the 3,3,3,3,4,3,3,3,3,4... pattern. As such the AVR does NOT need to do floating point "* 3.2" operations. Just doing the sourceX+3 thing with N==5 leading to sourceX+3+1 would have the same effect.

Of course now I have my basic GetPixel and SetPixel I can try replacing the *3.2 stuff with exactly that to verify that the integer version leads to the same result (it will).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm..
Should it be N == 4 ?

Although I don't see how that would have the observed effect.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Quote:
LCD_SetPoint(desty, destx, rgb);

Is this correct? It is, I think, more usual for x to be first:
i.e.

LCD_SetPoint(destx, desty, rgb); 

However, it looks to me as though something is out by a factor of two.


yea, that's correct, because if I reverse it, I have a reversed picture...

LCD_SetPoint(desty, destx, rgb); 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Hmm..
Should it be N == 4 ?

Although I don't see how that would have the observed effect.


I'll give a try and see what happens
thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 if (ny == 5) and  if (nx == 5)

try with if (ny == 4) and if (nx == 4) ?

There are four blue stripes on diagonal now....I'm not sure it's from there...?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you 100% sure that the image you are using is 1024 by 768?

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Are you 100% sure that the image you are using is 1024 by 768?

100% sure for the size, it is 1024 by 768...something missing on the code ? thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW I changed my code to use the integer version of 33334 stepping:

HBITMAP hNewBmp;
HDC hEditDC;
int x, y, n, m, destx, desty;
hNewBmp = CreateCompatibleBitmap(GetDC(hwnd), 320, 240);
hEditDC = CreateCompatibleDC(GetDC(hwnd));
SelectObject(hEditDC, hNewBmp);
n = 0;
m = 0;
destx = 0;
desty = 0;
for (y=0; y<768; y+=3) {
	for (x=0; x<1024; x+=3) {
		SetPixel(hEditDC, destx, desty, GetPixel(MemDCFILE, x, y));
		destx++;
		m++;
		if (m == 5) {
			x++;
			m =0;
		}
	}
	destx = 0;
	desty++;
	n++;
	if (n == 5) {
		y++;
		n = 0;
	}
}
BitBlt( hDC, 10, 10, 320, 240, hEditDC, 0, 0, SRCCOPY );
DeleteObject(hNewBmp);
DeleteDC(hEditDC);

and the visual result was identical.

The structure of this is very similar to what you are attempting except that I post increment n/m whereas you pre-increment.

Another thought about your data - what file format is it? If 24 bit RGB BMP and accessing the pixel data directly then apart from the obvious "upside down thing" in Windows BMP remember about the padding to 32 bit boundary though I would have thought 1024 wide images hit this naturally anyway as 1024 * 3 is 3072 and 3072 / 4 is 768 which is an integer multiple.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

to clawson,

for (y=0; y<768; y+=3) {
   for (x=0; x<1024; x+=3) { 

I don't understand...how to relate it with my code ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Another thought about your data - what file format is it?

It's 24 bit BMP RGB 1024x768

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't understand...how to relate it with my code ?


You use:

for(y = 0, ny = 0; y < sourceheight; y += 3, ny++)
       for(x = 0,nx = 0; x < sourcewidth; x += 3,nx++)

I chose not to mix the n/m stuff in with the outer for() loops (though I guess I could have) and in your code sourceheight=768 and sourcewidth=1204 so your loops really say:

for(y = 0,; y < 768; y += 3)
       for(x = 0; x <1024; x += 3)

Unless you can spot it I think we have identical code in this sense.

Quote:
It's 24 bit BMP RGB 1024x768

Yup I realised that from studying your code some more (I did find hdr_256 to be quite a confusing name though!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I took a 320 by 240 image, displayed it on my LCD, then displayed a scaled version(works out at 100 by 75).
This is what it looks like. Sorry about the terrible photo, it's just a crappy phone camera picture, and there's some sort of moire pattern artifact going on. It actually looks pretty good in real life.
The scaled image is upside down, you say? Yes, it is. On the big picture I read the bitmap backwards, as Windows saves from the bottom up. On the scaled image, I didn't want to complicate things that much.

Attachment(s): 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
void ScaleIt(uint32_t FlashAddr)
{
uint8_t buffer[64];
uint32_t FileSize;
uint32_t BitmapOffset;
uint32_t BitmapWidth;
uint32_t BitmapHeight;
uint32_t RowSize;
uint32_t colour;
uint32_t scalex, scaley;
uint32_t pixeloffs;
TFT_SetBotRight(319,240);	
DataFlashReadBlock(FlashAddr, buffer, 64);		// Read the header info
FileSize = (buffer[2]) | (buffer[3] << 8) | (buffer[4] << 16) | (buffer[5] << 24); // Get the file size
BitmapOffset = (buffer[10]) | (buffer[11] << 8) | (buffer[12] << 16) | (buffer[13] << 24);	// Get the offset to pixel data
BitmapWidth = (buffer[18]) | (buffer[19] << 8) | (buffer[20] << 16) | (buffer[21] << 24);   // Get the bitmap width
BitmapHeight = (buffer[22]) | (buffer[23] << 8) | (buffer[24] << 16) | (buffer[25] << 24);  // and the height
RowSize = ((24 * BitmapWidth + 31) / 32) * 4;			// Work out the row size

for(scaley = 0; scaley < 75; scaley++)
	{
	for(scalex = 0;scalex < 100; scalex++)
		{
		pixeloffs = BitmapOffset + ( (scaley * 32 / 10) * RowSize) + (scalex * 32 / 10) * 3;
		TFT_SetTopLeft(scalex, scaley);
		DataFlashReadBlock(pixeloffs, &colour, 3);		
		TFT_WritePixel(colour);	
		}	
	}
}

My bitmpap is simply stored in a flash chip, rather than being part of a filing system, but the general principle is the same.

And the reason I didn't start out with 1024 by 768 is that my Flash chip isn't quite big enough.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It works already, thanks guys..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Already?

:D

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And you shrunken image looks nice?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Already?

:D

Yes it did, thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:
And you shrunken image looks nice?

Yes it does,
have a look on youtube, after the green and white box are 1024x768 shrunken

https://www.youtube.com/watch?v=P3rlm3_uV0k

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting background music choice - thank goodness it doesn't sound like a 70's porn video...

.. oh wait a minute!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR digital picture frame. Perhaps it should appear on hackaday?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bianchi77, we want to know what you did that finally fixed your image shrinking code!

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Bianchi77, we want to know what you did that finally fixed your image shrinking code!

You haven't figured out bianchi77's M.O. yet, John?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:
Bianchi77, we want to know what you did that finally fixed your image shrinking code!

You haven't figured out bianchi77's M.O. yet, John?

Obviously not.
I don't think I'll be helping him/her again.

Four legs good, two legs bad, three legs stable.

Pages