Support and General Use > Plugins/Viewers

Can't open .jpg's

<< < (2/2)

Jason Arthur Taylor:
Saratoga, you implied I wrote that mp3 files won't play, but I said "play properly." Only the latter probably encompasses displaying the album art, which is included to be displayable to the viewer.

You also wrote,

"Fortunately, the more memory intensive jpeg variants are almost never used in practice."

I disagree.  Progressive is the default in some image software programs.  And, I mean, I didn't write those scripts to waste time, and the op isn't the only one who has posted about this.  It is a common thread around here. 

Regarding ram usage of progressive jpgs, I, of course, disagree with you all, as usual.  See, e.g., https://www.linkedin.com/pulse/low-memory-progressive-jpeg-decoding-giles-payne , which states, in part,

"I was sure that there must be another way to decode these images without using hundreds of megabytes of RAM and so I came up with my low memory progressive-mode JPEG decode implementation.

How the implementation works

Two passes are used to decode progressive mode JPEGs. The first determines the locations of each of the scans; the second does the actual decoding.

Pass Number One - reads through the file to determine the location of all the "start of scan" markers. Initializes a "scan context" for each scan.
Pass Number Two - restores the scan context of the first scan, reads one row of MCUs, saves the updated scan context for the first scan. Repeats for the second scan and all subsequent scans until a complete row of MCUs is decoded. Outputs the completed row of MCUs and repeats for the second row of MCUs etc. The implementation relies on the data source being "seekable" where as the original libjpeg does not. A "check_seekable" method has been added in the jpeg_source_mgr to check for working implementations of the standard C library seek/tell functions." 

He then specific gives examples in which ram required to process progressive jpgs went down by factors as high as ~400.  (It probably scales with image size, so smaller images probably wouldn't get that kind of benefit.)  The code is already in c, so it shouldn't be too much work to swap out the prior code.  On the other hand, that would be a little work, and I'd guess it probably won't happen, especially since, according to Paul's recent email to me, nobody here is capable of getting any of the paypal donation money, the amount of which is unknown anyway.

__builtin:

--- Quote from: Jason Arthur Taylor on January 28, 2017, 11:03:01 PM ---The code is already in c, so it shouldn't be too much work to swap out the prior code.  On the other hand, that would be a little work, and I'd guess it probably won't happen, especially since, according to Paul's recent email to me, nobody here is capable of getting any of the paypal donation money, the amount of which is unknown anyway.

--- End quote ---

None of us are paid to work on Rockbox. If you want to see a feature added, you'll have to either to do it yourself or find an interested dev, which is unlikely.

saratoga:
If you think you can get progressive jpeg decoding working, go for it. I think it will be very hard given the constraints, but maybe you can find something that other people have overlooked.

Navigation

[0] Message Index

[*] Previous page