Rockbox Technical Forums
Support and General Use => Plugins/Viewers => Topic started by: vision_scientist on July 08, 2006, 04:12:31 PM
-
Hello,
What is the maximum file size (in MB) of jpegs viewable by the H320 with rockbox?
I would check the wiki, but it is down and I need to know quickly (that is, before the eBay auction ends!).
Thanks
-
Viewable while music is playing, or while it isn't?
Because Rockbox can view extremely large files if you allow it to stop the music and use the rest of the available memory.
-
...it's the maximum I'm after, i.e. without music playing, although knowing the numbers for both with and without music would be good too. Do you have the actual figures (I'm fortunate enough to have a camera that generates what I think of as extremely large images)?
-
i haven't found a maximum size and i have use reasonably big jpeg files shoot with Nikon D100.
it just takes a little more time to load and you are asked to stop music playback.
but if you have a 18Mpix Mamya or similar - there might be a limit. but i dont think so.
-
if i stop playback, i can load 8 megapixel pics, but it takes a long time
-
Top knowledge! Thanks everyone!
-
vision_scientist, remember that the rockbox JPEG-Viewer is still limited in it's format.
Some (progressive?) JPEGs will not displayed -
you'll see the not very expressive error message "unsupported -4" instead :-[
BTW, is it somehow possible to resize the JPEGs to the screen size with the viewer?
I only see the center of my picture and have to scroll...
(and the backlight also switches off - even in slideshow mode)
-
you can only zoom in on the picture with the viewer (or at laest as far as I know) by pressing NAVI, but I don't think that you can zoom out
if you resize the picture on your computer to 1024X768 it should fit the screen perfectly and still be able to zoom in a ways
I have no idea how to fix the backlight......sorry
-
The resizing problem was my mistake - the viewer resizes the pictures to fit to the display on default.
If you press NAVI it resizes it to other standard sizes (800x600, ...)
So my fault was that I always pressed NAVI instead of Play... ::)
But the problem with the backlight is really annoying when you use the slideshow to present some pictures to somebody else and this person is suddenly saying: "hey, your screen goes dark - what's going on"!
It would be nice if the viewer either automatically switches off the backlight handling and keeps it always on or that it presents a setting for this :)
-
Hello,
I've only had Rockbox on my iriver for a few months now and I can't say anything to the backlight issue except that it's a bit annoying and the only way to fix that I know if so far is to change it in the "General Settings".
As for Rockbox resizing pictures to fit the screen however: I have some photos on my iriver that appear considerably smaller than the screen at first and I have to press NAVI once just to get them as big as the screen. I have made these pictures smaller by reducing the size and resolution.
What could be the reason for the smaller appearance of these pictures?
Is there any chance of that backlight issue being resolved in one of the next builds?
Thank you!
Greetings,
whatchamacallit
-
About the backlight problem:
I wrote a bug report at the tracker and also created a patch which fixes the problem
and keeps the backlight always on when the JPEG plugin is active:
FS#5652 — Backlight switches off when in JPEG plugin (http://www.rockbox.org/tracker/task/5652)
Enjoy - and tell me if it works for you ;)
About the picture sizes: the JPEG plugin chooses the nearest proportional size which fits the screen -
dependend on the original size the resized size could be a lot smaller than your screen size.
If you press navi it resizes it to sizes which are bigger that your screen.
Test it and try if you can scroll inside your picture by pressing on of the cursor keys after you pressed NAVI...
-
http://www.rockbox.org/tracker/task/5652
thats the real link ;)
drunk that early, Massa ? *shakes head* :D
-
Grrmbbblll!!! >:(
I wrote url="http://..." and it generates url=http://"http://..." - weird ???
And of course I'm not drunk - but it's so hot, it may be a heat stroke which makes me a bit mad :P :-* ;)
-
Really, that should've been a feature request, not a bug report.
The backlight turning off when keys aren't pressed is of course, intended behaviour at the moment, so any request that it do otherwise would really be a feature request rather than a bug report.
A "bug" is only when things don't work the way the manual or documentation says they're supposed to.
-
Of course it's a bug - or are you able to view a picture slideshow when the backlight switches off?
Or do you want to tell me that for you that is correct behaviour? :o
Sorry - but that doesn't make sense at all for me (and I think for most other people, too).
BTW, the backlight is permanently switched on in a lot of plugins
(xobox, wormlet, video, tetrox, starfield, spacerocks, plasma, oscilloscope, grayscale, fire, demystify, credits, clock, brickmania)
So why not switch it permanently on in the JPEG plugin? ???
And if the manual explicitely says something like "the backlight will always switch off after the defined timeout" it's already wrong and I suggest to change the manual, too! ;)
-
Those plugins have the ability to overwrite the backlight control.
All I'm saying is that it's not a bug for it NOT to have its own alternate behaviour. It may not be the most usable option, but because it follows the default behaviour, it's working as intended (however annoying) until the intent changes.
-
Who is able to "change the intent"?
The original author of the plugin?
Or the majority of core developers?
Or the majority of users?
Or Santa Claus? :P
"until the intent changes" - that's nitpicking! >:(
Why must a simple change (I intentionally don't say "bugfix")
which makes an existing feature much more usable be
devaluated and brought back to "it's annoying but it
works as intended"?
Would it help if I open a poll to change the behaviour or keep it?
Or if (as you said) "the intent changed"?
I doubt it, but who knows...
Sorry, but the whole discussion is really ridiculous in my eyes! >:(
-
I never said the change itself is bad.
All I said was that it's not a bugfix. I definitely think this change should go into CVS. My ONLY point was that it's not a bugfix just because something seems annoying, if in reality the code is supposed to make it happen, and right now the code is supposed to make the backlight go off unless the plugin overrides it.
-
O.K. I did calm down now ;)
Actually I don't care if it's called a bugfix or a feature/change request.
My only problem was, that in one case it could be included before 3.0
and in the other not (because of feature freeze).
But it seems that was only my problem - it has already been accepted :D
-
I figured this was the only way to end the discussion :P