PictureAlbum updated
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    I am happy to say that I have finally REALLY got PictureAlbum working on MorphOS - it has been successfully tested on an Efika :-)

    It is not yet finished, but you can download the 'preview' of it here.

    To give you an idea about it, here are a couple of old pictures from the OS4 version:
    PictureAlbum_1.png
    PictureAlbum_2.png

    What it does is allow you to browse your folders, see thumbnails of all the pictures, open those pictures & put them where you like on the screen. When you go back to the folder, the pictures will appear where you left them! You can also rename/delete/move pictures.

    All the previous "picture cataloguers" & "photo management" programs I've tried on the Amiga felt clunky, and in general sucked, so this is my attempt to "do it right". I want it to be simple & natural to use, with minimal configuration needed.

    NOTE: Currently pictures of 256 colours or less do not look very good. I hope to fix this.

    [ Edited by ChrisH 28.10.2011 - 15:19 ]
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »08.10.11 - 11:52
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    Divinity
    Posts: 498 from 2009/9/8
    @ChrisH

    thanks
    It's very slow in preview (dramatically slow vs ShowGirls)
  • »08.10.11 - 13:33
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    @Divinity
    EDIT: You are right. It seems about 5x slower than ShowGirls at generating thumbnails, which is rather strange. I had assumed the slow speed was due to the Efika... I will investigate, thanks.

    Seems that now it no-longer crashes nor gives wrong colours, I need to look at optimisations. I already found one piece of code that I should have removed, but hadn't, which could slow things down.

    [ Edited by ChrisH 08.10.2011 - 16:02 ]
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »08.10.11 - 14:13
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    @Divinity
    I've done some tests on a folder a JPGs without any embedded EXIF thumbnails (which is the worst likely case). In that case ShowGirls is about 6 times faster at generating & showing thumbnails.

    I've measured what is taking PictureAlbum's time, and it mainly comes down to:
    44% loading the pictures by datatypes
    32% scaling the pictures into a thumbnail size by graphics.library
    16% saving the thumbnails by datatypes

    As you can see, datatypes accounts for 60% of the total time taken, and apparently is horrendously slow (at least on MorphOS) compared to whatever method ShowGirls is using. So it seems I need to find a faster way of loading JPEGs, and if possible saving too. There may be a library I can use for this...

    Another 32% of the total time is simply taken by graphics.library scaling the picture. I don't think I'm doing anything wrong (I tried making a few changes), so it seems graphics.library is simply a poor way to scale pictures. Finding a faster alternative for this will probably be harder, as it will likely have to be MOS-specific, and will probably use the graphics card to do the scaling...

    Before I tackle speeding things up, I'm going to concentrate on fixing the few remaining MorphOS-specific issues that affect functionality.

    [ Edited by ChrisH 08.10.2011 - 18:54 ]
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »08.10.11 - 17:51
    Profile Visit Website
  • MorphOS Developer
    Krashan
    Posts: 1107 from 2003/6/11
    From: Białystok...
    So it seems I need to find a faster way of loading JPEGs, and if possible saving too.

    For loading you can try Reggae, a few lines of code... Ehem... or rather you will be able to do it after MorphOS 3.0 release ;-).

    [ Edited by Krashan 08.10.2011 - 20:35 ]
  • »08.10.11 - 19:25
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    I have released an updated 'preview' of PictureAlbum here.

    The changes for this release:
    - NEW: (MorphOS) Greatly reduced video memory usage.
    - BUG: You could not change the location of the Cache.
    - BUG: (MorphOS) Pictures with < = 256 colours now display properly.

    This brings the MorphOS version up to about the same level as on other OSes.

    [ Edited by ChrisH 13.10.2011 - 23:45 ]
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »13.10.11 - 21:49
    Profile Visit Website
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    @ChrisH

    To generate thumbnails graphics.library is not necessarily the best option. You may get better results with your own scaling engine and using CPU only. For example Ambient is very good at it and generates thumbnails very quickly.

    You can scale bitmaps using TinyGL which allows using filters.

    There is jfif.library available in MorphOS to load JPEG images. I dont know if it is faster than datatypes but may allow using some optimizations what datatypes dont.
    1 + 1 = 3 with very large values of 1
  • »14.10.11 - 05:37
    Profile
  • MorphOS Developer
    CISC
    Posts: 619 from 2005/8/27
    From: the land with ...
    ShowGirls uses jfif.library directly, and is much faster than datatypes, the main reason is probably that datatypes converts the data to RGBA while ShowGirls uses YCbCr directly.


    - CISC
  • »14.10.11 - 07:02
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    I have released an updated 'preview' of PictureAlbum here.

    The changes for this release:
    - BUG: Scrolling should be faster & smoother on AROS, MorphOS, and maybe OS4 too.
    - BUG: Video memory usage on MorphOS should definitely be reduced now.
    - BUG: It will hopefully work on the Linux-hosted version of AROS.
    - CHG: Should benefit from various general bug fixes made to PortablE.
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »28.10.11 - 11:00
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    itix,
    Quote:

    You can scale bitmaps using TinyGL which allows using filters.

    Unfortunately I don't have a clue about any 3D APIs, and looking at 'tgl/glut.h' I haven't even got a clue where to start. (So looks like I'll only be able to do h/w accelerated scaling on OS4.)

    Perhaps I could gain some improvement by using graphics.library's ScalePixelArrayAlpha() plus either ReadPixelArray() or WritePixelArray()? ScalePixelArrayAlpha() mentions "uses hardware acceleration on dedicated hardware", but I'm not clear on whether that is relevant for commonly used 3D cards?
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »18.03.12 - 11:16
    Profile Visit Website
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    ScalePixelArray() / ScalePixelArrayAlpha() is accelerated on the most common gfx cards.

    Using GL to scale bitmaps requires more work in terms of setting up initial setup but this is what I use in Frodo port for TGL scaling:

    Setup:
    Quote:


    STATIC ULONG mSetupTGL(struct Display_Data *data, ULONG width, ULONG height, ULONG depth)
    {
    struct Library *TinyGLBase;

    TinyGLBase = OpenLibrary("tinygl.library", 0);

    if (TinyGLBase)
    {
    data->TinyGLBase = TinyGLBase;

    if ((__tglContext = GLInit()))
    {
    data->Texture = (GLubyte *)AllocTaskPooled(DISPLAY_X * DISPLAY_Y * 4 * sizeof(GLubyte));

    if (data->Texture)
    {
    if (data->RastPort.BitMap)
    data->RastPort.BitMap = AllocBitMap(width, height, depth, BMF_DISPLAYABLE|BMF_MINPLANES, _screen(data->ehn.ehn_Object)->RastPort.BitMap);

    if (data->RastPort.BitMap && glAInitializeContextBitMap(data->RastPort.BitMap))
    {
    glViewport(0 , 0 , width , height);
    glClearColor(0.0, 0.0, 0.0, 1.0);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();

    glWindowPos2f(0, 0);
    glPixelZoom(1.0f * (float)width/(float)DISPLAY_X, -1.0f * (float)height/(float)DISPLAY_Y);

    glColorTable(GL_COLOR_TABLE, GL_RGBA, 256, GL_RGBA, GL_UNSIGNED_BYTE, data->TGLColours);

    data->GLRender = TRUE;
    return TRUE;
    }
    }
    }
    }

    mCleanupTGL(data);
    return FALSE;
    }



    Cleanup:
    Quote:


    STATIC VOID mCleanupTGL(struct Display_Data *data)
    {
    struct Library *TinyGLBase = data->TinyGLBase;

    if (TinyGLBase)
    {
    if (__tglContext)
    {
    if (data->Texture)
    FreeTaskPooled(data->Texture, DISPLAY_X * DISPLAY_Y * 4 * sizeof(GLubyte));

    if (data->RastPort.BitMap)
    glADestroyContextBitMap();

    GLClose(__tglContext);
    }

    CloseLibrary(TinyGLBase);

    data->Texture = NULL;
    data->TinyGLBase = NULL;
    data->GLRender = FALSE;
    __tglContext = NULL;
    }
    }



    Scaling/drawing:
    Quote:


    STATIC VOID mUpdateTGL(struct Display_Data *data, struct RastPort *rp, ULONG mleft, ULONG mtop, ULONG mwidth, ULONG mheight, GLubyte *buf)
    {
    struct Library *TinyGLBase = data->TinyGLBase;

    glDrawPixels(DISPLAY_X, DISPLAY_Y, GL_COLOR_INDEX, GL_UNSIGNED_BYTE, buf);
    glFinish();

    data->GfxBufOk = TRUE;
    BltBitMapRastPort(data->RastPort.BitMap, 0, 0, rp, mleft, mtop , mwidth, mheight, 0xc0);
    }



    It is understandable if you dont want to go this route. It requires relatively lot code to get it done and this example is designed for LUT8 bitmaps.

    I think it is better use SW scaling. With altivec optimizations it is very quick.
    1 + 1 = 3 with very large values of 1
  • »18.03.12 - 13:08
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    number6
    Posts: 483 from 2008/8/10
    @itix

    I recall that the answer (OS3.x days) was to use jpegtools. There is absolutely no doubt that it was a dramatic speedup.
    Example:If an image is 2000x2000 and you need 60x60 for a thumb, you only need load and process the data required for the thumb.

    If this is similar to what you are discussing, then I've misunderstood.

    #6
  • »18.03.12 - 14:59
    Profile
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    @number6

    I guess the same could be achieved by using jfif.library in MorphOS 2.

    But problem with jfif.library and jpegtools it is not generic solution. It works for one picture format enve though JPEG is the most used format.
    1 + 1 = 3 with very large values of 1
  • »18.03.12 - 16:08
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    number6
    Posts: 483 from 2008/8/10
    @itix

    Agreed. No different back in OS3.x days.

    You just use both methods depending on filetype.
    Overall though, since most files are apt to be .jpg, it's a dramatic improvement.

    #6
  • »18.03.12 - 16:15
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    @itix
    Thanks for the TinyGL code. I shall give it a try at some point.

    BTW, is there any way to check whether a bitmap is stored in video memory or not? I can't see a way with CGX. (Or would a CGX allocation with BMF_DISPLAYABLE fail if there was no video memory available?)
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »23.03.12 - 16:39
    Profile Visit Website
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    You could call GetBitMapAttr() and check BMF_DISPLAYABLE flag. If you alloc bitmp with BMF_DISPLAYABLE flag and there is no vmem left it will not fail but you may get fast ram bitmap instead. CGX may clone your bitmap to vmem later.

    (If I am mistaken please let cyfm or bigfoot correct me.)
    1 + 1 = 3 with very large values of 1
  • »23.03.12 - 17:26
    Profile
  • Paladin of the Pegasos
    Paladin of the Pegasos
    Jupp3
    Posts: 1193 from 2003/2/24
    From: Helsinki, Finland
    Quote:

    Using GL to scale bitmaps requires more work in terms of setting up initial setup

    Can't you just set projection and modelview to identity, (in which case a -1 to 1 quad will fill the entire viewport), then (before drawing, of course) glMatrixMode(GL_TEXTURE); and do all transformations (glTranslate, glRotate, glScale etc.) you want?
  • »27.03.12 - 09:03
    Profile Visit Website
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    @Jupp3

    I guess I could, I just dont have enough experience about OpenGL.
    1 + 1 = 3 with very large values of 1
  • »27.03.12 - 10:22
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    ChrisH
    Posts: 167 from 2009/11/26
    itix,
    Quote:

    Quote:

    is there any way to check whether a bitmap is stored in video memory or not?

    You could call GetBitMapAttr() and check BMF_DISPLAYABLE flag.

    Unfortunately that doesn't *seem* to work. The BMF_DISPLAYABLE flag is always set, even when (I believe) it isn't stored in video memory.
    Author of the PortablE programming language.
    It is pitch black. You are likely to be eaten by a grue...
  • »01.04.12 - 16:36
    Profile Visit Website