UTFT_SDRaw library: Color issue when rendering .RAW files loaded on SD card

Other Hardware Displays
1

I've successfully run both the "Demo Portrait" demo program (UTFT_tinyFAT library) and the "SdRaw_800x480" demo program (UTFT_SdRaw Library) using my Arduino Mega and ITDB50 TFT with ITDB02 Mega Shield. All sample images show up perfectly.

However, problems arise when I swap out the filepath for other .RAW images I have put on the SD card (2GB SD). All images I have tried were saved to BMP or Jpeg using Photoshop CC and then converted to RAW format using the Henning Karlsen's ImageConverter565 v2.1 (tried both the GUI and the console version) as well as his online version. All images are sized upon saving in Photoshop to 800px x 480px, and I have tried resizing to that size using the converters as well. I have also tried using the following methods in photoshop:

  • RGB and grayscale modes
  • 4, 8, 16, 24, and 32 bit depth (options when saving to bitmap)

Regardless of the parameters I use to save the image, an irregular color pattern is displayed on the LCD when running the "SdRaw_800x480" demo. Also, when running the "Demo Portrait" program with the UTFT_tinyFAT library, I get a "File not found error"

The only lines I have adjusted in the sample program are (changes shown in bold italics):

  • line 32: UTFT myGLCD(ITDB50, 38, 39, 40, 41);
  • line 89: myFiles.load(0, 0, 800, 480, "Phases_Timelapse_800_480_16bitRGB.RAW", 1 , 1);

Any suggestions?

FullSizeRender (3).jpg
FullSizeRender (3).jpg480×640 85.8 KB

FullSizeRender (2).jpg
FullSizeRender (2).jpg480×640 129 KB

2

alejandrosklar:
Regardless of the parameters I use to save the image, an irregular color pattern is displayed on the LCD when running the "SdRaw_800x480" demo. Also, when running the "Demo Portrait" program with the UTFT_tinyFAT library, I get a "File not found error"

The only lines I have adjusted in the sample program are (changes shown in bold italics):

  • line 32: UTFT myGLCD(ITDB50, 38, 39, 40, 41);
  • line 89: myFiles.load(0, 0, 800, 480, "Phases_Timelapse_800_480_16bitRGB.RAW", 1 , 1);

Any suggestions?

Yes :stuck_out_tongue:

If you had looked through the example, you would have found that

  myFiles.load(20, 20, 440, 440, fname440, 4, 0);
  mytime1 = millis() - mytime;
  cout << F("Time to draw 440x440 raw (4*buffer) (non inverted colour) ") << mytime1 << F(" ms") << endl;
  delay(5000);
  mytime = millis();
  myFiles.load(20, 20, 440, 440, fname440, 4, 1);
  mytime1 = millis() - mytime;
  cout << F("Time to draw 440x440 raw (4*buffer) (inverted colour) ") << mytime1 << F(" ms") << endl;

As such, should not have been too much of a stretch to try this....

myFiles.load(0, 0, 800, 480, "Phases_Timelapse_800_480_16bitRGB.RAW", 1 , 0); ????

The text outputs (non inverted colour) after myFiles.load(20, 20, 440, 440, fname440, 4, 0);
and (inverted colour) after myFiles.load(20, 20, 440, 440, fname440, 4, 1);
were possibly too subtle for you?

There are several threads where I have gone into extensive detail of the useage of the functions of my library if only you had done a google on Site:Arduino.cc UTFT_SdRaw :blush:

And now about the problems with UTFT_tinyFAT.......... why on earth are you surprised you are getting file not found errors? You read the manual for tinyFAT of course, or even the information on the tinyFAT download page on Henning's website.....

The library supports FAT16 formatted SD cards up to 2GB in size. 4GB FAT16 formatted SD cards does not work. Long filenames are not supported. Keep your filenames compliant with the old 8.3 standard.

!!!!!

As always, leave Karma, thanks.

Regards,

Graham

3

Thank you for pointing out the issue with long filenames with Henning's library. Images now display fine using his library.

As for the issue I'm running into using SdRaw, I had already tried adjusting the color invert parameter. This is not an issue with inverted colors. You can tell because it's a grayscale image, so if inverted it would still show up grayscale.

I will just use Henning's library for this project as it's time sensitive. I think you have done a great job with your library, but I would HIGHLY recommend documenting it better, as it is rather inefficient to search through forum threads to locate usage information for a library. And it will save you time not having to re-answer questions over and over :wink:

And I will leave you Karma, but traditionally the concept of Karma is that it all evens out in the end. Thus good deeds are performed not for a specific return to a specific action, yet rather to elevate the balance of one's world and the average good associated with a person and his/her surroundings. Not exactly how Karma is interpreted on this site, and you do a great job answering people's questions about your library, so thank you again.

4

Strictly speaking I see how you might think that, but even greyscale WOULD appear as colours with the invert bit set incorrectly for the source you are using, since what the invert bit does is switch the MSB and LSB.

Eg, a normally formed word of a single pixel in RGB565(raw) would be RRRRRGGG GGGBBBBB, so then if you invert it........... would be GGGBBBBB RRRRRGGG, so grey would no longer be grey....

The reason I introduced this feature was for my own reasons, since I wrote a program that produced over 100,000 240*240 raw images, and I used the traditional MSB, LSB storage notation, which gave incorrect colour when drawn on screen, but images produced by Henning's convertor were correct.

So why didn't I make my images the same as Henning's? Because I wanted to use a Windows paint program to view them, and my images had the correct colour, but Henning's images were inverted in the Windows program. I approached Henning about correcting his raw convertor, but he argued he had such a large user base already using his libraries and image convertor, he would just leave it the way things were. So I made my library capable of handling MSB, LSB or LSB, MSB.

Hope this clears up for you why your statement about greyscale remaining greyscale is wrong! 8)

Regards,

Graham

5

Ok Fair enough. It is still not the cause of this issue, because the image does not show up correctly when using inverted logic.

I will resume troubleshooting the issue once I wrap this project up, as I would prefer to use your library in the long run. Will post if I discover the issue.