jpeg decoding in full asm

[Thorham]

Originally Posted by meynaf

They could have thought "what's the point ?" if they had enough knowledge about computers, but they hadn't

Well, if they had real knowledge about computers, they would surely now the point

Originally Posted by meynaf

Indeed

Originally Posted by meynaf

You're right : there'll probably be no common code between jpeg and png. The bit reading stuff could have been compatible if there wasn't that marker hit detection stuff right in the middle of it.

Alternatively if you want to see some bit reading stuff for inspiration, you can find some in flac.s of my sound player.

Yeah, sucks. Maybe I'll take your approach, and find some good source code. Maybe zlib is good.

Originally Posted by meynaf

Apparently yes. I have successfully displayed a grayscale picture.

That's amazing, a whole gray scale picture

Originally Posted by meynaf

Now it does a little bit more but it's not much more useful.

Just not finished enough. We'll see what it's going to be.

Originally Posted by meynaf

You can't reuse existing drivers. They're meant for a particular operating system, using them would be like porting a program to another plaform.

It depends on the driver. If it's interface is easy enough to use, it can be done. On the other hand, with 'modern' os drivers, this is probably just not the case. Of course, you only really need the hardware's most basic features, so it may still be somewhat doable.

Originally Posted by meynaf

If your dictionnary is fixed (does not dynamically evolve while running) then a dichotomic search will be better than a hash table. Just a suggestion

Yep, that's true. But I'm not sure if the dictionary is going to remain fixed, and hashing is already very fast. On the other hand, tokenizing to make a list of uniques, and then sorting those to get the search table, seems quite reasonable.

Originally Posted by meynaf

Yeah, no argument there

I've been playing around with the assembler parts of your jpeg decoder, and have found that I can modify those files without them having any effect when I compile the project Any pointers on what's going on?

[meynaf]

Originally Posted by Thorham

Yeah, sucks. Maybe I'll take your approach, and find some good source code. Maybe zlib is good.

In the actual viewers zlib is probably directly used ; this could be useful as starting point like I did with the jpeg lib.

Originally Posted by Thorham

That's amazing, a whole gray scale picture

I have advanced a little and can display some (most ?) color ones, but the progressive jpeg support is somewhat broken
(it works with the files I've tested, but anytime I try a new one I discover something unexpected )

Originally Posted by Thorham

Just not finished enough. We'll see what it's going to be.

It's somewhat working. But the code is quite dirty because it has got modified a lot of times before it accepted to work

Speedwise, I've understood why I'm faster on lulu.jpg than on yuna.jpg : it's simply that the former is in 1x1 (and therefore does not need upsampling) whereas the latter is in 2x2.
So guess what ? Visage is probably using a box filter upsampler (if I do the same I'm faster heheh).

Originally Posted by Thorham

It depends on the driver. If it's interface is easy enough to use, it can be done. On the other hand, with 'modern' os drivers, this is probably just not the case. Of course, you only really need the hardware's most basic features, so it may still be somewhat doable.

If you only get hardware's basic features, you'll end up with an old VGA display

That said, it is true that some different boards look the same because using the same chip, hence you can have some sort of "generic" driver.

If you really want to look at drivers to see what's going on in them, then you can start with some linux driver sources.

Originally Posted by Thorham

I've been playing around with the assembler parts of your jpeg decoder, and have found that I can modify those files without them having any effect when I compile the project Any pointers on what's going on?

Oh, well. It seems I should have told you to phxass that v.s to get a new v.o before re-linking the project...

[Thorham]

Originally Posted by meynaf

Visage is probably using a box filter upsampler (if I do the same I'm faster heheh).

That has given me an idea for quick mode. Why not forget about the upsampling stage and just skip straight to the ycbcr to rgb converter? For 2x2 just read 4xY and 1xCB and 1xCR. That should improve the speed a good bit. For the other cbcr sizes, just use a different loop. Of course, it's only useful for a quick mode. Seeing how the ham renderer already has this, I don't see why the jpeg part can't, either. On the other hand, how much speed do you think we'll gain with this 'trick'?

Originally Posted by meynaf

If you really want to look at drivers to see what's going on in them, then you can start with some linux driver sources.

If I would start hardware coding on the peecee, I would certainly do that. These drivers are open source, and probably a great way to start peecee coding.

Originally Posted by meynaf

Oh, well. It seems I should have told you to phxass that v.s to get a new v.o before re-linking the project...

Maybe you should have Seeing how c accepts assembler in it's source code, I just thought the assembler parts were used automatically. Well, I've learnt something new, again Oh, and guess what, I've tried changing the upsampling part, but I think I used a jpeg with 1x1 cbcr

[meynaf]

Originally Posted by Thorham

That has given me an idea for quick mode. Why not forget about the upsampling stage and just skip straight to the ycbcr to rgb converter? For 2x2 just read 4xY and 1xCB and 1xCR. That should improve the speed a good bit. For the other cbcr sizes, just use a different loop. Of course, it's only useful for a quick mode. Seeing how the ham renderer already has this, I don't see why the jpeg part can't, either. On the other hand, how much speed do you think we'll gain with this 'trick'?

You wouldn't probably gain much as the upsampling part doesn't take a lot of processing power (as compared to the rest), but it may be worth a try anyway. There are already a lot of such tests in my code, activated - or not - by some equ at start.

Either they damage the quality or they don't gain speed on all images

Originally Posted by Thorham

If I would start hardware coding on the peecee, I would certainly do that. These drivers are open source, and probably a great way to start peecee coding.

Yes, they're open source, and that's exactly why I suggested them

On the other hand they're probably quite unreadable...

Originally Posted by Thorham

Maybe you should have Seeing how c accepts assembler in it's source code, I just thought the assembler parts were used automatically. Well, I've learnt something new, again Oh, and guess what, I've tried changing the upsampling part, but I think I used a jpeg with 1x1 cbcr

I didn't put the asm part directly in the project because the assembler wouldn't cope with my sort of phxass-only code.
Else it's possible to directly include them.

But now I think it's rather pointless. Look at what I've put in the zone for you to play with and tell me what you think of it

[Thorham]

Originally Posted by meynaf

You wouldn't probably gain much as the upsampling part doesn't take a lot of processing power (as compared to the rest), but it may be worth a try anyway. There are already a lot of such tests in my code, activated - or not - by some equ at start.

Certainly worth a try, since any speed gain for quick viewing is good.

Originally Posted by meynaf

Either they damage the quality or they don't gain speed on all images

For quick mode, damaging the quality is not relevant, just speed. Good quality jpeg viewing is never going to be very fast on a '030 anyway, so an ugly quick mode will at least let you know what an image is, if that's all you want to know.

Originally Posted by meynaf

Yes, they're open source, and that's exactly why I suggested them

On the other hand they're probably quite unreadable...

Hopefully not, but you never know. I'm not going to get my hands dirty with peecee hardware coding any time soon, though, so it's no biggie.

Originally Posted by meynaf

But now I think it's rather pointless. Look at what I've put in the zone for you to play with and tell me what you think of it

I can describe what I think of it in one word: BITCHIN' Seriously, I've already replaced all but one (png) file types in my diro config with v, and I'm very happy with it. Thanks a million bucks, mate Also, now that the c parts are gone, I can have a much better look at your code. Oh, and I like the English comments

Maybe it's time for you to start advertising your viewer on the eab, I'm sure other people will also like it a lot.

Edit: I just tried v with a progressive jpeg, and all I can say is that v just became even better in my opinion. All the other ones I've seen, do it in multiple passes which you can see on screen, slowing everithing down to a crawl, not v, however. Again, ace program, meynaf.

Edit2: (note: All this is for quick mode) After looking at the idct code, I decided to try a little stunt and replace a bunch of muls values with the closest power of two... Guess what? For a good few it doesn't matter a lot. Next, I replaced them with shifts. For negative muls values: Shifts, and then neg... Same result: Degradation, but not that much. It seems you can get away with quite a lot of fiddling around with those muls and it saves quite a few frames. I never would have expected this at all, and although I haven't replaced all possible muls with shifts, I already got the grey scale image down from 128 frames to 120 Combine this trick with all the other quick and dirty tricks, and the quick mode is indeed going to be quick.

Edit3: Have tried removing some of the fixed value muls completely, and although there is some degradation, overall it still isn't huge! The gray image is now displayed in about 117 frames. I wonder how much less this can become with the other dirty tricks.

Edit4: I've uploaded the modified jpeg.s file and a bmp file (based on your gray test image) rendered with the modified jpeg.s to the zone. The jpeg is your original. Let me know what you think of it for a quick mode, although I'm sure you'll agree it's quite bearable for such purposes.

Edit5: I've discovered a bug which causes v to crash, I'll let you know when this exactly happens when I find out how to reproduce the error.

[meynaf]

Originally Posted by Thorham

Certainly worth a try, since any speed gain for quick viewing is good.

See the out_mcu routine then.

Originally Posted by Thorham

For quick mode, damaging the quality is not relevant, just speed. Good quality jpeg viewing is never going to be very fast on a '030 anyway, so an ugly quick mode will at least let you know what an image is, if that's all you want to know.

If only speed is relevant, then you can just use sjfif (prob'ly available from Aminet). Ugly quality, but its speed leaves the others far behind.

Originally Posted by Thorham

I can describe what I think of it in one word: BITCHIN' Seriously, I've already replaced all but one (png) file types in my diro config with v, and I'm very happy with it. Thanks a million bucks, mate Also, now that the c parts are gone, I can have a much better look at your code. Oh, and I like the English comments

Glad you like my translated comments, I did them just for you

For the png, what I have to say is that when I tried to display one with Visage, it just crashed
What do you use to show them ? (I remember a few crashes with akpng datatype too)

If you're still interested in implementing the png, then I can write some sort of skeleton codec for you.

Originally Posted by Thorham

Maybe it's time for you to start advertising your viewer on the eab, I'm sure other people will also like it a lot.

Huh, advertising ? Dunno...

Originally Posted by Thorham

Edit: I just tried v with a progressive jpeg, and all I can say is that v just became even better in my opinion. All the other ones I've seen, do it in multiple passes which you can see on screen, slowing everithing down to a crawl, not v, however. Again, ace program, meynaf.

Hopefully it is ! That progressive support was quite a pest to implement and took me ages ! Not to mention the code's still a little bit on the dirty side...

The program "jpegaga" (see Aminet) doesn't do it in several passes. Yet it's still very slow

Originally Posted by Thorham

Edit2: (note: All this is for quick mode) After looking at the idct code, I decided to try a little stunt and replace a bunch of muls values with the closest power of two... Guess what? For a good few it doesn't matter a lot. Next, I replaced them with shifts. For negative muls values: Shifts, and then neg... Same result: Degradation, but not that much. It seems you can get away with quite a lot of fiddling around with those muls and it saves quite a few frames. I never would have expected this at all, and although I haven't replaced all possible muls with shifts, I already got the grey scale image down from 128 frames to 120 Combine this trick with all the other quick and dirty tricks, and the quick mode is indeed going to be quick.

That dct is probably not the right one to hack this way. The fast-int one should be better suited (see attached thingy behind).

Originally Posted by Thorham

Edit3: Have tried removing some of the fixed value muls completely, and although there is some degradation, overall it still isn't huge! The gray image is now displayed in about 117 frames. I wonder how much less this can become with the other dirty tricks.

For that particular image, the winners are :

test2a equ 1  ; idct - shortcut 1st coef if test2
huffdeq equ 1  ; dequant coefs ac in huffman rather than dct

(just change equ 0 to equ 1 on those lines and see the result)

Originally Posted by Thorham

Edit4: I've uploaded the modified jpeg.s file and a bmp file (based on your gray test image) rendered with the modified jpeg.s to the zone. The jpeg is your original. Let me know what you think of it for a quick mode, although I'm sure you'll agree it's quite bearable for such purposes.

Not quite visible on this particular image I quite agree. It's much more visible on lulu.jpg ; not on overall but try to read the little inscriptions to the bottom left...

Originally Posted by Thorham

Edit5: I've discovered a bug which causes v to crash, I'll let you know when this exactly happens when I find out how to reproduce the error.

Oops... yes, it's important for me to remove that.
On which image did it happen ?

[Thorham]

Originally Posted by meynaf

If only speed is relevant, then you can just use sjfif (prob'ly available from Aminet). Ugly quality, but its speed leaves the others far behind.

So, how does it compare to V? And, can it handle progressive jpegs as well as V?

Originally Posted by meynaf

Glad you like my translated comments, I did them just for you

Thank you

Originally Posted by meynaf

For the png, what I have to say is that when I tried to display one with Visage, it just crashed
What do you use to show them ? (I remember a few crashes with akpng datatype too)

I use vPng from aminet, which is here: http://aminet.net/gfx/show/vPNG.lha

Originally Posted by meynaf

If you're still interested in implementing the png, then I can write some sort of skeleton codec for you.

Yes, I am, but I would wait with doing that until I have some functional code up and running. Thanks for the offer, but it's a little early.

Originally Posted by meynaf

Hopefully it is ! That progressive support was quite a pest to implement and took me ages ! Not to mention the code's still a little bit on the dirty side...

The program "jpegaga" (see Aminet) doesn't do it in several passes. Yet it's still very slow

Well, yes, it is! Anyway, why was it so hard?

Originally Posted by meynaf

That dct is probably not the right one to hack this way. The fast-int one should be better suited (see attached thingy behind).

Ah, even faster, eh? Tested it, and I think it used 100 frames for the gray image. Not bad, and can be improved with the mentioned hacks.

Originally Posted by meynaf

Oops... yes, it's important for me to remove that.
On which image did it happen ?

I don't think it happens on any particular image. Still testing. It's probably some unknown circumstance that causes it. Once I find out how to consistently reproduce the bug, you'll be the first to hear!

[meynaf]

Originally Posted by Thorham

So, how does it compare to V? And, can it handle progressive jpegs as well as V?

No, it can't handle progressive jpegs, and lamentably fails on some images (e.g. my grayscale test-image). But it's twice faster.

Originally Posted by Thorham

I use vPng from aminet, which is here: http://aminet.net/gfx/show/vPNG.lha

Thanks, I'll check that one.

Originally Posted by Thorham

Yes, I am, but I would wait with doing that until I have some functional code up and running. Thanks for the offer, but it's a little early.

Ok then.

Originally Posted by Thorham

Well, yes, it is! Anyway, why was it so hard?

Why was it hard ? Separate DC/AC decodings, which are done sometimes one component at a time, sometimes mixed up, different layout of the MCUs, different huffman encoding (when it's huffman at all)...

Originally Posted by Thorham

Ah, even faster, eh? Tested it, and I think it used 100 frames for the gray image. Not bad, and can be improved with the mentioned hacks.

Anyway if a poor quality one has to be used, it's that one.

Originally Posted by Thorham

I don't think it happens on any particular image. Still testing. It's probably some unknown circumstance that causes it. Once I find out how to consistently reproduce the bug, you'll be the first to hear!

Hmm... didn't you simply have an unstable system because you hacked a little bit too much ?
What was the file type ?
What was the error ?

[Thorham]

Originally Posted by meynaf

No, it can't handle progressive jpegs, and lamentably fails on some images (e.g. my grayscale test-image). But it's twice faster.

Twice the speed, but no progressive/gray scale is quite unacceptable. Shame they didn't make it more compatible...

Originally Posted by meynaf

Thanks, I'll check that one.

You're welcome. But I must admit I don't use it a lot, so I have no idea of how stable it is.

Originally Posted by meynaf

Ok then.

I'm just getting things organized right now. As I'm not great with c, I'm seriously thinking about starting from scratch on this one. The zlib page only explains the deflate algorithm, not inflate, which I need, so I need some time to get my mind around it.

Originally Posted by meynaf

Why was it hard ? Separate DC/AC decodings, which are done sometimes one component at a time, sometimes mixed up, different layout of the MCUs, different huffman encoding (when it's huffman at all)...

Hmm, sounds bloody awful! I sure wish I had the patience to do that sort of stuff.

Originally Posted by meynaf

Anyway if a poor quality one has to be used, it's that one.

Cool. And don't worry, poor it will be.

Originally Posted by meynaf

Hmm... didn't you simply have an unstable system because you hacked a little bit too much ?

Could be, but it's unlikely. Further more, my system isn't really hacked. I only use a few system add-ons, and the only thing is the stupid mallware which was discussed in your ham8 thread. But...

Originally Posted by meynaf

What was the file type ?
What was the error ?

So far, it's been bmp and jpeg. As for the error, it's a full crash. It seems to happen when I load another image during the small progressive jpeg decoding delay, but I'm unsure. It's probably something small, and it's pretty hard to reproduce, even when I'm trying really hard. It almost seems random.

[meynaf]

Originally Posted by Thorham

Twice the speed, but no progressive/gray scale is quite unacceptable. Shame they didn't make it more compatible...

Some gray scale images are supported, but, yes, it's not very compatible. Then again I'm not sure I have the latest version.

Originally Posted by Thorham

You're welcome. But I must admit I don't use it a lot, so I have no idea of how stable it is.

Tested. It looked pretty good to me, it's fast and displayed all my PNG images - apart it doesn't really support the progressive PNGs (but why did they do that progressive stupidity AGAIN ?).

Originally Posted by Thorham

I'm just getting things organized right now. As I'm not great with c, I'm seriously thinking about starting from scratch on this one. The zlib page only explains the deflate algorithm, not inflate, which I need, so I need some time to get my mind around it.

Deflate and inflate are exactly the same : it's just called deflate when decrunching, and inflate when crunching.

Originally Posted by Thorham

Hmm, sounds bloody awful! I sure wish I had the patience to do that sort of stuff.

I had the patience and it took me several days. <sigh>
But seeing how you enjoyed it makes me think it was more than worth

Originally Posted by Thorham

Cool. And don't worry, poor it will be.

Oh, I'm confident it'll be poor, no problem

But it ought to be fast. I think a "quick" option isn't worth if it's not at least twice faster than the regular high quality one, don't you agree ?

Originally Posted by Thorham

Could be, but it's unlikely. Further more, my system isn't really hacked. I only use a few system add-ons, and the only thing is the stupid mallware which was discussed in your ham8 thread. But...

What I was saying is that you might have accidentally broken something in the DCT or elsewhere, which apparently isn't the case.

Originally Posted by Thorham

So far, it's been bmp and jpeg. As for the error, it's a full crash. It seems to happen when I load another image during the small progressive jpeg decoding delay, but I'm unsure. It's probably something small, and it's pretty hard to reproduce, even when I'm trying really hard. It almost seems random.

But a full crash should give you "software failure" and an error number, eh ? So what was it ?

Your test case sounds like a low memory situation anyway (low chipmem ? maybe low fastmem ?), so I'll investigate on that field.

[Thorham]

Originally Posted by meynaf

Some gray scale images are supported, but, yes, it's not very compatible. Then again I'm not sure I have the latest version.

Hmm, I've never had it. I think I'm going to check the latest version, if it's still developed.

Originally Posted by meynaf

Tested. It looked pretty good to me, it's fast and displayed all my PNG images - apart it doesn't really support the progressive PNGs (but why did they do that progressive stupidity AGAIN ?).

Same here, it seems like a good program. That progressive rubbish is there for the same reason it's in jpeg, and in todays world, thats just completely useless. But it shouldn't be that hard to implement.

Originally Posted by meynaf

Deflate and inflate are exactly the same : it's just called deflate when decrunching, and inflate when crunching.

Deflate and inflate seem like separate algorithms to me. At least that's what I've seen in the zlib archive. I've finally managed to compile some part of it: An easy inflate routine called Puff, which was contributed to the zlib archive, and it is written for simplicity. With that, I shouldn't have a problem getting a good basis for my own inflate routine. One last thing: Deflate crunches, and inflate decrunches

Originally Posted by meynaf

I had the patience and it took me several days. <sigh>
But seeing how you enjoyed it makes me think it was more than worth

Those must have been some intense days then. And oh yeah, I certainly enjoy

Originally Posted by meynaf

Oh, I'm confident it'll be poor, no problem

But it ought to be fast. I think a "quick" option isn't worth if it's not at least twice faster than the regular high quality one, don't you agree ?

Yes, with all the crap I can do to it, it will certainly be poor You're right, though. If there isn't a substantial speed increase, it's not worth it. Twice as fast is a little bit much. What about 1.5 times? That would shave of a lot of time with very big jpegs, such as 1280x1024, or worse, 1600x1200. Those larger images seem to become more and more common these days.

Originally Posted by meynaf

What I was saying is that you might have accidentally broken something in the DCT or elsewhere, which apparently isn't the case.

No, thats not the case, as I'm using your unaltered version.

Originally Posted by meynaf

But a full crash should give you "software failure" and an error number, eh ? So what was it ?

Your test case sounds like a low memory situation anyway (low chipmem ? maybe low fastmem ?), so I'll investigate on that field.

Erm, I didn't write it down. I always click the guru away asap. Next time I'll write it down. My fast mem is 16mb, and when booted, I have about 1.6mb of chip. But it might be that loading multiple images simultaneously by accident, causes the crash. Had any 'luck' in making it crash?

[meynaf]

Originally Posted by Thorham

Hmm, I've never had it. I think I'm going to check the latest version, if it's still developed.

The last I have is the 1.72.

Originally Posted by Thorham

Same here, it seems like a good program. That progressive rubbish is there for the same reason it's in jpeg, and in todays world, thats just completely useless. But it shouldn't be that hard to implement.

Not hard to implement, certainly. Just cumbersome.

Originally Posted by Thorham

Deflate and inflate seem like separate algorithms to me. At least that's what I've seen in the zlib archive. I've finally managed to compile some part of it: An easy inflate routine called Puff, which was contributed to the zlib archive, and it is written for simplicity. With that, I shouldn't have a problem getting a good basis for my own inflate routine. One last thing: Deflate crunches, and inflate decrunches

I only had a quick look on the zlib. Now let's see what you can do with all that

Originally Posted by Thorham

Those must have been some intense days then. And oh yeah, I certainly enjoy

Intense days, sure they were ! But it also was a great experience and I certainly won't regret.

Originally Posted by Thorham

Yes, with all the crap I can do to it, it will certainly be poor You're right, though. If there isn't a substantial speed increase, it's not worth it. Twice as fast is a little bit much. What about 1.5 times? That would shave of a lot of time with very big jpegs, such as 1280x1024, or worse, 1600x1200. Those larger images seem to become more and more common these days.

Well, the bare minimum here is what other viewers can do, more precisely what the quickest of them actually does.
If you can do your 1280x1024 image in 400 frames or less then it's ok.

Originally Posted by Thorham

No, thats not the case, as I'm using your unaltered version.

I expected this... <sigh>
When you try your best to get a crash, do you experience enforcer hits (or similar things with another program) ?

Originally Posted by Thorham

Erm, I didn't write it down. I always click the guru away asap. Next time I'll write it down. My fast mem is 16mb, and when booted, I have about 1.6mb of chip. But it might be that loading multiple images simultaneously by accident, causes the crash. Had any 'luck' in making it crash?

I didn't make it crash. But how can you possibly load multiple images simultaneously ? Are you using some sort of tool manager ?